This is the mail archive of the
cygwin-patches@cygwin.com
mailing list for the Cygwin project.
Re: exec after seteuid
Corinna Vinschen wrote:
>
> On Mon, Jun 09, 2003 at 11:14:56AM -0400, Pierre A. Humblet wrote:
> > Don't drop the setegid()!!!! seteuid(new user) would see the gid of system
> > (which can be 544 or 18 in old installs), which may not be in the token
> > created from login with password. If it's not, a new (passwordless)
> > token will be created. If you run with 544 you won't see that bad behavior.
>
> Btw., if that's true, it's a bug, IMHO. It undermines the job,
> cygwin_set_impersonation_token() is designed for. If a passwordy
> token is given, it should be used if the uid given to seteuid32()
> corresponds to the SID in the token. If the gid is taken into
> account too strictly, there's no clean way to switch back and forth
> between the privileged and the unprivileged account multiple times
> w/o changing the source code of the application each time, the
> set(e)?[gu]id is called. Basically the code would have to be changed
> to
Let's look at the way a pop server works.
First the user logs in with a password. That's Cygwin specific login
code, platform dependent, calling cygwin_set_impersonation_token()
on NT.
Later, in the bowels of the program, you find logic like
if (mail is kept under home dir)
{
setgid(user_gid);
setuid(user_uid); <= must use token from cygwin_set_impersonation_token()
e.g. to access shared drive
}
else /* mail is kept in system spool dir */
{
setgid(mail_gid); <= gives full access to spool dir
setuid(user_uid); <= must discard token from cygwin_set_impersonation_token()
and create a new token
}
It looks like all applications handle setgid/setuid in pairs,
and that's why the current design works.
If we want to handle the gid and uid individually then we would
have to create a token when we change gid (expensive and unnecessary
in all cases I have seen), and we will have to keep more than one
token around (specially those created by cygwin_set_impersonation_token()).
I have considered doing that (it's easy), but it hasn't been necessary so
far.
Pierre