This is the mail archive of the cygwin-patches@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: 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


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