Mail Archives: cygwin/2001/05/28/18:48:57
Hi Corinna...
I was wondering (and wishing very much) if, with your new method for
changing the UID, I can still use a password when that is desireable? That
is, if I have a password (in my case with ssh/sshd) will the new process
work as it has in the past, with all of the rights of the UID/password?
I would like this because I can use password authentication with ssh/sshd
when I really care about the access rights of the remote process. For
applications where it is not critical, your new method is much more
convenient :=).
This would make interoperation with the (future) sshd partial authentication
code easier also. Then if I want a password, I set it up in the sshd_config
file. But now, all of the messy code for "if I did not get a password" can
be removed.
So, please tell me how the new method will work in the presence of a
password?
Thanks,
...Karl
>From: Corinna Vinschen <cygwin AT cygwin DOT com>
>To: cygwin <cygwin AT cygwin DOT com>
>Subject: [IMPORTANT]: New code in Cygwin 1.3.2 allowing to change user
>context without password
>Date: Wed, 23 May 2001 11:33:17 +0200
>
>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:cygwin AT cygwin DOT com
>Red Hat, Inc.
>
>--
>Want to unsubscribe from this list?
>Check out: http://cygwin.com/ml/#unsubscribe-simple
>
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -