Re: exec and EXECSERVERS

[Paul Jarc]

tb@becket.net (Thomas Bushnell, BSG) wrote:
> prj@po.cwru.edu (Paul Jarc) writes:
>> I don't know this Hurd stuff very well (or at all, nearly), but in
>> Unix terms, I'd say whatever code sets uid=euid (if any) in a setuid
>> situation should take responsibility for clearing dangerous
>> environment variables (or any other attributes of the process state
>> inherited from the pre-setuid situation).  As long as uid!=euid,
>> dangerous environment variables can be safely preserved but ignored.
>
> Except that this is totally non-Unix.  The kernel does not change your
> SHELL environment variable when you do a setuid exec, nor should it.

I agree - the kernel does not set uid=euid.  (It preserves the old
uid, and sets the new euid according to the file's owner.)  I was
saying something different: if there is a program running in a setuid
situation (i.e., its real uid is different from its effective uid)
that changes its real uid to match its effective uid (I'm not claiming
this happens often), and then runs another program, then that other
program will have no way of knowing that it is in a setuid situation.
So the first program must take responsibility for cleaning the
environment, etc.

> It's normally the responsibility of a setuid program to be careful,
> not the entity that starts it...

Right: as long as uid!=euid, all code can tell that it's in a setuid
situtation, and so each program that uses a variable that might be
dangerous can ignore the variable in that situation.  It's only when
some previous code has destroyed that information by setting uid=euid
that there's trouble.

> Whether an environment variable is "dangerous" is a very hard, very
> non-local thing to determine, in general.  That's why a special hack
> just for EXECSERVERS seems like a mistake.

I wasn't advocating that special hack.

> The only reason it comes up is because Unix programs might get run on
> the Hurd, and they don't know that the Hurd has a *new* dangerous
> environment variable.

Ah, ok.  That complicates things.  Well, by the general principle
above, I'd say EXECSERVERS should definitely be ignored when starting
a setuid program, and also when the calling process already has
uid!=euid.  Then the only problem cases left are Unix programs which
set uid=euid and clean the dangerous variables they know about (which
wouldn't include EXECSERVERS), and which later exec another program.
I'd imagine those are pretty rare.


paul