Robert Elz <kre@munnari.OZ.AU> writes:
> If you mean "setuid processes don't dump core", then that's fine, as
> long as the process continues being setuid - but after it does a setuid(0)
> and then an exec or two down the chain, what's the mechanism then?
If the process calls:
setuid()
seteuid()
setreuid() (with either id != -1)
setgid()
setegid()
setregid() (with either id != -1)
setgroups()
successfully, or sets user or group ID on exec, the P_SUGID flag is
set. (it is cleared only on non-set-id exec.) If P_SUGID is set, the
process won't dump core. So, set-id programs are safe.
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-)
> At the very least, I'd suggest a little bit of thought about this before
> it gets entrenched enough that when bugs are found workarounds need to be
> invented, instead of just yanking the mechanism.
yah.
cgd
--
Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.