Gandhi woulda smacked you <greywolf@starwolf.com> writes:
> # Gandhi woulda smacked you <greywolf@starwolf.com> writes:
> # > # I'd say that this inherited attribute -- as well as other attributes
> # > # which should exist and be inherited, such as unaligned access handling
> # > # -- should revert to their system-wide defaults upon set-id exec (and
> # > # maybe anything that sets P_SUGID, but i'm less sure about that).
> # > # 
> # > # Obviously, these attributes don't exist yet, so code to reset them or
> # > # otherwise properly handle them can't exist yet.  8-)
> # > 
> # > So you're thinking that login now has to change its uid, and exec
> # > something that execs the user's login shell.  This means that a user's
> # > login shell will not dump a core unless we jump through this hoop.
> # 
> # Uh, why do you say this?  i don't think it follows from anything i said...
> 
> Okay, maybe I'm confused.  I'll tell you where I went, and you tell me
> where I got lost.
> 
> 1.  login is a set-uid executable.  When it is run, P_SUGID will be set.
> 2.  login will then setuid from root to the user it has verified.  P_SUGID
>     is set here.
> 3.  As I saw it stated, because a successful set-id has occurred in login
> 	(twice, but once is all it takes), when login execs the shell
> 	the shell will also have P_SUGID set.  Thus you have to exec
> 	something as the user, without setting ids, which will then
> 	execute the shell in order to clear P_SUGID.

when login exec's another process, that process _will not_ have
P_SUGID set.  since that exec isn't starting a set-id executable
(i.e. it's _not_ a "set-id" exec), nothing would be reset from what it
was right before the exec and P_SUGID would be cleared by the execve()
call.




cgd
-- 
Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.