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


> 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.




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