[EMAIL PROTECTED] (Thomas Bushnell, BSG) wrote: > [EMAIL PROTECTED] (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 _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
