On Mon, 13 Jan 2003, Richard Troy wrote:
Hi All,
One of the long-time known problems (limitations) with cygwin has been the
lack of the ability to switch user identities, such as is done with the
suid bit, and su utility. I know that as of last April, there was some
talk of using the cygserver as a partial answer (with shared memory as a
possible attack/leak point). I'm wondering about what's happened or is
happening on this point and I've got a few practical questions and
observations that relate.
The primary question is simple, but does not appear to be reflected in the
archive: Is anybody working on cygserver to get this technology
implemented?
I also observe that the sshd seems to be doing something a bit like this -
how is it doing so? If we have an sshd doing something like this, why not
have an su program? In fact, I have been taking advantage of the client
side of ssh to ask a program be run for you on the remote system. Yeah,
performance sucks, but then, at least it works! It does make for a crude
'su' program!
A somewhat related observation is that when I use ssh to create a session
on the system, it seems to work just fine HOWEVER, it does not have good
access to disk shares. How might I go about providing my ssh clients who
are a different user than is logged in into windows (or when noone is
logged in!) access to disk shares? These other users, if logged into
windows directly, have privileges for their own disk share access. The
question then is, how can I mount volumes just for them? Do they need
their own drive letters, or will they be private? ...I've read up on
mount, but don't think this solves the problem: Simply accessing mounts
which another user has the credentials for isn't quite right. The
credentials should be based upon the rights of the user who's using
them... That is to say, how/where do I tell it what username and password
to use for the shares accessed? Or, will windows apply the correct
credentials on my behalf? (I guess I could figure that out on my own with
a lot of testing, but it'd be nice to get a straight answer if someone
knows, please.)
Thanks, and happy CYGWINning!
Richard
Richard,
There is a fairly detailed discussion of this in the cygwin-developers
list archives for the past couple of months.
If I recall the details correctly, Windows NT security model allows for
switching the effective userid, but requires a special permission which by
default is given only to the LocalSystem user. Thus, programs like
'login' or 'su' can only work for a user possessing such a permission.
sshd and telnetd (and cygserver) run under the LocalSystem account, so
they are able to switch user context to the authenticated user. This is
why 'ssh user@localhost' works. One of the goals of cygserver, by my
recollection, was to provide a service running as LocalSystem accessible
to the cygwin DLL to perform tasks that require root-like permissions.
Since this service would have to be accessible to non-root processes (by
necessity), security would indeed be an issue.
Technically, nothing prevents an administrator on a machine from giving
this permission (called, I *think*, 'Create a token object') to a user
other than LocalSystem, which will then allow that user to run 'login'
successfully. It is impractical from a security standpoint, however, to
give this permission to all users.
I think the situation is similar with the network shares, and one needs a
token to access them, but these are murky waters, and I don't claim to
fully understand these issues.
I'll only add that there also seems to be a difference between a
password-authenticated user token and a pubkey-authenticated user token,
and then I'll shut up and let experts like Pierre Humblet or Corinna
Vinschen correct my certainly naive interpretation.
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk!
-- /usr/games/fortune
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
