This is the mail archive of the cygwin-developers@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]
Other format: [Raw text]

RE: Subauthentication


At 02:18 PM 12/14/2002 +0100, Hartmut Honisch wrote:
>>I guess I have to look at the authentication code more closely and talk to
>Pierre about how to avoid calling the PDC to speed things up.

>Couldn't we just always call subauth and just check if it was successful?
>That way, a user could install the cygwin subauthentication module on
>whatever machine he needs to.

I don't have a problem with installing the cygwin subauthentication module
on whatever machines, and neither with calling subauth even for domain users.

However there are servers applications, such as mail servers, that 
don't need to create a session. Their main motivation to setuid is to avoid
running as root when it's unnecessary. The processes they create run for as 
little as a fraction of a second. 

Contacting the DC for such applications has a lot of relative overhead. The 
the main drawback however is that the call can fail after a long delay if the
DC serving the user is unreachable. The NTCreateToken call does not need to 
contact the DC and it is thus safer.

To decide if the tradeoff is in favor of subauth, I suggest checking if
setgroups has been called. 
Serendipitously, setgroups is not called by ftpd, telnetd, sshd (i.e. when
there
is a session) but it is often called by systems such as mail servers.
In addition, when setgroups has not been called, create_token attempts to
contact
the DC (to get the groups) and thus loses its advantage.

Cygwin has a long history of problems with DCs and the current code has
evolved
(latest change was by Corinna in get_initgroups_sidlist ()) to return success 
even when it fails to contact the DC (in that case the token may be missing
some 
groups). 

>
>Like in the following algorithm:
Yes, but just add an "if"

>// Always call subauthentication. If a subauth dll is installed (either
>locally or on the PDC),
>// it will succeed. Otherwise, it will fail
>
if (setgroups_has_been_called)
>SubauthToken = CallSubauthentication(...);
else SubauthToken = INVALID_HANDLE;

>// Check if subauthentication was successful
>if(IsValidToken(SubauthToken))
>{
>  if(verify_token(SubauthToken))
>    // Use subauthentication token
>    NewToken = SubauthToken
>  else
>    // Call NtCreateToken, but use SubauthToken's logon session id
>    NewToken = create_token(SubauthToken.LogonSessionId, ...);
>}
>else
>{
>    // Call NtCreateToken and use current logon session id
>    NewToken = create_token(CurrentLogonSessionId, ...);

The pseudo code has a token leak with SubauthToken. It should be managed
carefully, in light of your remarks in another mail about the duration of
the session. Consider the case of a parent process that repeatedly setuid
and launch a subprocesses. 
When should the tokens be deleted in the parent?
Currently the last token created by create_token is kept (the previous one
is deleted when a new one is created) in case it will be needed again soon.

By the way, do we know if including CurrentLogonSessionId does any good?

>}

Pierre


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