This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

more info, RE: [IMPORTANT]: New code in Cygwin 1.3.2 allowing to change user context without password


Corinna,

THANKYOU for this info, its some of that unpublished doc that explains
some of the bahaviors that popped up recently.

Anyway, I had run into a case with rshd a few days ago where
if I did a rsh as user B to a rshd spawned by inetd running as user A
then the USER variable would be set to B but id -a would show the id of user
A

It had also been the case rshd would respond with "no remote directory"
if nobody was logged into the NT box with inetd running as a service.
(now it gives a consistant can't fork; try again)

Now (with the -13 update) it seems to correctly get the right id when
rshd spawns of processes.

It is also interesting to note that it picks up all of the user env vars
of the user running inetd from a shell, like it is picking up
HOMESHARE/HOMEPATH
of the user running inetd, and not of the user invoking rsh.

I am still running inetd from a shell for rshd to work, since I still get
fork failed; try again if inetd is run as a service...

It may also be the case that a reboot is needed after installing -13 and
the other stuff yesterday to get the new proper id on rshd, but I'm not
sure about that.

I'll try -14 tomorrow

-Mark Keil


> -----Original Message-----
> From: Corinna Vinschen [mailto:cygwin@cygwin.com]
> Sent: Wednesday, May 23, 2001 5:33 AM
> To: cygwin
> Subject: [IMPORTANT]: New code in Cygwin 1.3.2 allowing to change user
> context without password
> 
> 
> 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@cygwin.com
> Red Hat, Inc.
> 
> --
> Want to unsubscribe from this list?
> Check out: http://cygwin.com/ml/#unsubscribe-simple
> 

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]