In message <43C80E13.20403@tadpole.com>, "Garrett D'Amore" writes:

>
>Btw, we might want kern.defcorename and a new kern.defsuidcorename
>sysctl, the latter can use a full path name, without imparing ordinary
>behavior that we are all used to for non-suid processes.
>

I think that that's a very good idea -- the namespace isn't cramped 
enough for us to want to overload that field.  

I'm still trying to wrap my brain around all of the security 
implications of this proposal.  I don't think they've all come out yet.
For example, we can't just go with the effective uid for the owner of 
the dump; many setuid programs shed their permissions at some point.
We need the saved uid.  We also have to worry about setgid programs -- 
will the real user own the core dump?

The need for some such facility is clear.  Restricting it to root and a 
particular directory is at best a hack -- it's saying "we'll give you 
something, but we don't really understand what we're giving you, so use 
it with caution and let us know if you figure it out".  One of the very 
attractive things about Unix, way back when, was how many of its 
facilities weren't privileged.  That was a lovely change from, say, 
TSO.  SetUID, in particular, was designed as a general privilege 
elevation mechanism, one not restricted to the system administrator.  
It would be nice if we could make it easy for non-root to debug 
setuid programs.


		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb