exec after seteuid
Pierre A. Humblet
Mon Jun 9 16:41:00 GMT 2003
Corinna Vinschen wrote:
> On Mon, Jun 09, 2003 at 11:14:56AM -0400, Pierre A. Humblet wrote:
> > The right way is to save the system gid (as you save the system uid), and then
> > 1) setegid(user_gid), seteuid(user_gid).
> > Do the chdir
> > Later to do the utmp piece,
> > 2) setegid(saved_gid), setegid(saved_uid) (this goes back to the process token)
> > Finally,
> > 3)setgid(user_gid), setuid(user_uid).
> It doesn't work that way. When calling
> it changes the impersonated access token if priv_gid is in the group
> list of the new users token.
Nope. The token is only changed by set(e)uid(), never by set(e)gid().
Set(e)gid only changes the default group in the token, not the token
itself (that's your design, or perhaps even older, and it's just fine).
> That way, the final setuid again creates
> a new passwordless token.
> But keeping the gid completly untouched should work. Changing the euid
> to the new user uses the token given by cygwin_set_impersonation_token.
But the intermediate switch back to 18 will then create a new token and
discard the token given by cygwin_set_impersonation_token.
> Switching back to priv_uid again left the gid untouched so it just
> reverts to self.
> > Any initgroups() should/could go between 2 and 3.
> initgroups() is totally useless in login() since it's whole purpose is
> to use a token created by the system. initgroups will have no effect
> on that token.
Right. It was a side comment motivated by the presence of the initgroups()
in the original BSD login code. I was thinking that one day initgroups on
cygwin could do more stuff, allowing for example
which would then have you run with chris' groups. Today the "chris" is
disregarded. If initgroups does that, it has to be placed at the right spot.
More information about the Cygwin-patches