Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT cygwin DOT com Delivered-To: mailing list cygwin-developers AT cygwin DOT com From: "Hartmut Honisch" To: Subject: RE: Subauthentication Date: Fri, 13 Dec 2002 13:22:38 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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.