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.