Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com X-Originating-IP: [24.0.161.175] From: "Karl M" To: cygwin AT cygwin DOT com Subject: Re: [IMPORTANT]: New code in Cygwin 1.3.2 allowing to change user context without password Date: Mon, 28 May 2001 15:48:16 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 28 May 2001 22:48:16.0980 (UTC) FILETIME=[48F40140:01C0E7C8] 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 >To: cygwin >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