Mail Archives: cygwin-developers/2001/05/20/04:49:34
Hi all,
I have just added a 1500 lines patch to Cygwin which implements the
2nd way to change the user context without providing a password:
Creating a token by using the (undocumented) NtCreateToken call.
To say that first: This time I tested it on W2K _and_ NT4!
The new way of getting a token:
- The account which wants to change the user context needs the
SE_CREATE_TOKEN_NAME "Create a token object" privilege.
That's true by default only for LocalSystem and it's recommended
not to change that. However, for testing purposes or for creating
a special account for login purposes it's ok.
- As usual, the functionality is most happy with well maintained
/etc/passwd and /etc/group files. /etc/group isn't that important,
though, but adding all groups used as primary groups _with_ SID
is recommended.
- seteuid now tries first to create a token directly. If that fails
it falls back to trying subauthentication (which needs the SE_TCB_NAME
"Act as part of the operating system" privilege).
- The token created by the new `create_token' function (security.cc)
gets the same authentication id as the process token. That has the
following effect:
- If the process is running under LocalSystem account, the auth id
is the default system auth id which has only permissions to
access network shares which are open to everyone. Note that
this is different from open to all authenticated users! If one
has to give a password to access a share, that share is not
accessible from here.
- If the process is running under any authenticated user account,
the new token inherits the network access rights of the process.
Each network share is accessible with the same permissions as
the process owner have.
After the above description you probably guess that the user
don't has her own access rights on network shares as she would
have if logged on interactively. You guess right.
The problem is that the token don't have an unique authentication
id which is related to a logon session created by an interactive
logon of that very user.
Please give it a try. Personally I have used "su", a patched version of
"sshd" and my test application which I already sent to this group in
the thread " New subdirectory in winsup" for testing.
The patch to sshd is actually reverting a patch I did months ago.
That original patch prevents sshd from changing the user context
if now password authentication was made which is obviously not
what we want anymore. ;-)
If you want to use "su" for testing, don't fall for the "su -" trap
as I did! I have desparately searched for an error in my code since
"su -" didn't correctly change the user context for some reason, while
my own test app, "su" without dash and my patched sshd worked as they
should. Of course, I had no source for "su"... Half an hour and several
new debug_printf's later I suddenly realized, that "su -" completely
replaces the environment, even the CYGWIN variable. That means, after
switching the context suddenly the "ntsec" setting disappeared so that
half of the authentication code in `internal_getlogin' was skipped...
Have fun,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Developer mailto:cygwin AT cygwin DOT com
Red Hat, Inc.
- Raw text -