Hi folks,
originally I didn't intend to publish this that early but due to
errors in the code which may affect all NT/W2K users which run
apps changing the user context, I will tell what's new and what's
wrong:
New is that the seteuid function contains two new ways to create
a so called "user token", which is needed in NT/W2K to switch the
user context, without the need to provide a password.
One of these ways is somewhat complex and requires an additional
DLL in the windows system32 directory. That DLL is part of the
Cygwin CVS tree but it's currently not released. It has the
additional disadvantage not to work on NT4 but only on W2K.
What about that other way?
It's the use of an undocumented call in NT/W2K called NtCreateToken().
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 to create a token directly.
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.
Ok, what about the errors?
The first error in 1.3.2 is that parts of the code are only called
if ntsec is on while other parts are called always.
So, if you're using ntsec, you will see that it works (if your
/etc/passwd file is ok).
If you're not using ntsec, it has the weird effect that (according
to the circumstances) either changing the user context fails or that
changing the user context works but Cygwin doesn't know about that!
The second error is that even if you logon with a password
(creating a new logon session with exactly your permissions on
shares) that user token could get overwritten by a newly created one
using NtCreateToken(). The reason is that my code is somewhat...
overcorrect... in trying to figure out if the given user token
from the logon with password matches the current user settings...
which mostly isn't the case, unfortunately.
I'm of course woking on that and I'm pretty sure to have a nice
solution soon.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Developer mailto:[EMAIL PROTECTED]
Red Hat, Inc.
--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple
