This is the mail archive of the cygwin@sources.redhat.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: mount points and inetd


At 16:11 9/18/00 -0400, DJ Delorie wrote:
>It used to say "System" and "User" but I got complaints about those
>also.  If anyone wants to volunteer to add a "Help..." button, I'll
>gladly work with them to get those patches in.

hmm... what's setup's gui written in? I can certainly write up a
suggested bit of text after having been clearly wrong in my
understanding of the two ;) but I'll hold off on offering the
patches without knowing what it's coded in. :}

At 16:09 9/18/00 -0400, DJ Delorie wrote:
>I've also heard rumors that system mounts can't even be *used* by an
>account that doesn't have admin privs (does cygwin read the mounts
>with a read/write key, or a read-only key?).

not sure about 9x, but for NT4 users of class *GUEST* can use
system mounts just fine. (you've got to enable a policy to even
allow this class of user to login first if you wanna test that.)
so *any* user that can login can use them.

>Otherwise, if a consensus can be reached about what the best
>(i.e. safest) overall defaults are, it's easy to change.  Note that
>setup won't change your system if it's doing an upgrade; it defaults
>to whatever you had before.

My suggestion would be to assign /, /usr/bin, and /usr/lib as
system; as without them stuff stops working as soon as you load
the cygwin dll under an unusual user. (i.e. inetd)

(actually I'm in favor of symlinks for the /usr stuff so
that it doesn't show up as folders in windows explorer and
non-cygwin tools (like winzip) won't try to write stuff
out there; either that or touch empty files in their place
instead of creating directories.)

 From a *user* perspective the next thing I'd suggest is that
the issue with user mounts and their quirky persistence be
documented. While I grok the statement that their point is
to allow non-root, er non-admin, to mount stuff, they don't
exactly behave like user mounts in *nix. Case in point: user
A logs in, user mode mounts /home/A/foo, logsout, user B logs
in, user mode mounts /home/B/yada, user A telnets in, /home/A/foo
isn't mounted anymore. A runs screaming to the machine room,
shoves B of the console, logs in and... wtf? /home/A/foo is
there again.

Second case: user X logs in, mounts /yada, root (er, Administraitor)
tries to telnet in, telnet fails with connection refused,
Administraitor does a 'net start \\computer\inetd' from across the
lan, opps mount table just got scrogged and X's read from
/yada/master.rdb now resembles reading /dev/null.

been there, done that, not in a hurry to have the coronary again,
thanks. ;)

I don't even want to think about the ramifications in WTS?
anyone got one of those beasts they can play with? What happens
when you have more than one user login via the "console"?
Telnetting in through inetd doesn't seem to affect the mount
table, but what about comming in through a non-cygwin method
like WTS or RAS?

A part of that documentation would be a good explanation of
what user inetd runs under and where that user's mount table
is stored.

(note: someone is most likely going to come back and say this
is documented, I just needed to RTFM... well I've looked and
not found it, so if that's the case then the above can all be
replaced with a suggestion to document where the FM is...
perhaps in a big red blinking link on the setup screen.)


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]