Subject: Re: core dump filename format
To: Gandhi woulda smacked you <email@example.com>
From: Chris G. Demetriou <firstname.lastname@example.org>
Date: 09/10/1999 13:37:12
Gandhi woulda smacked you <email@example.com> writes:
> # Gandhi woulda smacked you <firstname.lastname@example.org> 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()
Chris Demetriou - email@example.com - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.