Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT cygwin DOT com>
List-Help: <mailto:cygwin-developers-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT cygwin DOT com
Delivered-To: mailing list cygwin-developers AT cygwin DOT com
Message-Id: <3.0.5.32.20021214130216.0082fb50@mail.attbi.com>
X-Sender: phumblet AT mail DOT attbi DOT com
Date: Sat, 14 Dec 2002 13:02:16 -0500
To: "Hartmut Honisch" <hartmut_honisch AT web DOT de>, <cygwin-developers AT cygwin DOT com>
From: "Pierre A. Humblet" <Pierre DOT Humblet AT ieee DOT org>
Subject: RE: Subauthentication
In-Reply-To: <NFBBLLCAILKHOEOHEFMHGEANCEAA.hartmut_honisch@web.de>
References: <20021214094332 DOT M19104 AT cygbert DOT vinschen DOT de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

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