Mail Archives: cygwin-developers/2000/07/19/16:06:51
Chris Faylor wrote:
>
> On Wed, Jul 19, 2000 at 09:54:14PM +0200, Corinna Vinschen wrote:
> >Chris Faylor wrote:
> >> I'm not sure why it is a problem even for when child == myself,
> >> actually.
> >
> >The below code could produce that (from spawn_guts):
> >
> >==== SNIP ====
> > /* Remove impersonation */
> > uid_t uid = geteuid();
> > if (myself->impersonated && myself->token != INVALID_HANDLE_VALUE)
> > seteuid (myself->orig_uid);
> >
> > /* Set child->uid to USHRT_MAX to force calling
> >internal_getlogin()
> > from child process. Set psid to NULL to play it safe. */
> > child->uid = USHRT_MAX;
> > child->psid = NULL;
> >
> > rc = CreateProcessAsUser (...);
> >
> > /* Restore impersonation */
> > if (myself->impersonated && myself->token != INVALID_HANDLE_VALUE)
> > seteuid (uid);
> >==== SNAP ====
> >
> >Assuming that myself==child, the last part (restoring the impersonation)
> >would be able to influence the child. The child would get a uid which
> >is the wrong one and additionally forbids calling internal_getlogin.
> >Hmm.
Nonsense! This can only effect things when the new impersonation
interface (cygwin_logon_user, cygwin_set_impersonation_token, setuid)
is used, which isn't the case in login-1.3. I'm as smart as before...
> Ok. So, it seems like you just don't need to do the second seteuid when
> mode == _P_OVERLAY . Right?
This might help. I will change that, however.
Corinna
--
Corinna Vinschen
Cygwin Developer
Cygnus Solutions, a Red Hat company
- Raw text -