www.delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin-developers/2002/12/13/07:22:45

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
From: "Hartmut Honisch" <hartmut_honisch AT web DOT de>
To: <cygwin-developers AT cygwin DOT com>
Subject: RE: Subauthentication
Date: Fri, 13 Dec 2002 13:22:38 +0100
Message-ID: <NFBBLLCAILKHOEOHEFMHMEAICEAA.hartmut_honisch@web.de>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <20021213125004.O7796@cygbert.vinschen.de>

> That sounds really interesting.  If we turn around the order in
> seteuid again (first call subauth, if that fails create_token) we
> could use that extra step as explained above to create a correct
> logon token.  It's just important, that the current NTCreateToken
> stuff still works as today if subauth is not installed.

There are scenarios where we would have to call both subauth and
create_token. Pierre pointed out some problems with setgid / setgroups and
subauthentication:

> Unfortunately the current setgid and setgroups are not completely
> Posix compliant.
> They do not take effect immediately, but only after a subsequent seteuid.
>
> For the new groups (from setegid or setgroups) to take effect, it
> is necessary to create a new token.
>
> In practice a setegid or setgroups call is always followed by a seteuid,
> and Corinna decided (wisely) to postpone token creation until the seteuid
> (instead of creating one after the setegid and a new one after
> the seteuid).
> That seems to be working well in practice.
>
> Note that there are scenarios (e.g. pop server) where a user logs in with
> a passwd and gets a token A with cygwin_logon_user calling LogonUser.
> The groups in token A are determined from the NT user database, not from
> setegid or getgroups.
> Later the pop server calls setegid(mail) followed by seteuid(user uid).
> In that case the token A cannot be used (at least if "mail" is not a group
> of the user). The seteuid routine then discards token A and gets
> a new token
>
> Note than in most cases (ssh, ftp, telnet), I expect subauthentication to
> yield a fine token.

So we would call subauth and use verify_token to determine whether the
returned token is suitable, i.e. contains all the required groups. If that's
not the case, we call create_token (we would need to add an additional
parameter for the logon session id to be used for the new token). We would
get a token with all required groups _and_ with a correct logon session id.

In case subauthentication doesn't work (because it's not installed or
whatever), we can still call create_token, but in that case with the
_current_ logon session id. In that case, the cygwin would behave as it is
now.



- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019