non-superuser chown(2)s considered harmful

[Tom Christiansen]

In article <1990Dec6.005358.6336 at dg-rtp.dg.com> goudreau at larrybud.rtp.dg.com (Bob Goudreau) writes:
:Yup, it's true.  System V has avoided this blemish from BSD.

Sounds semi-religious to me.  Blemish?

:But note that the SVID also mandates that a chown() will result in
:the set-UID and set-GID bits being cleared (unless the process has
:"appropriate privileges").  Otherwise, the system would have a gaping
:security hole:  I could create a file, chmod() it to mode 4755, chown()
:it to root, and voila:  I have a setuid root program!

I consider non-superuser chown(2)s harmful.  They screw up anyone who's
trying to do post-facto disk accounting or pre-emptive disk quotas.
Believe it or not, a lot of sites really do use one or both of these,
and giving away files makes this effectively useless.  These aren't
solely educational sites either. 

It also ruffles my security feathers.  Various programs realize that they
shouldn't source config files owned by someone other than the current
user, such as vi and the csh.  If I make a /tmp/.exrc, and someone cd's to
/tmp and vi's some file there, I still won't trick someone into sourcing
it because I can't make them own it.  The wide-open chown(2) call rampant 
at Death Star sites makes these security attempts futile.

--tom
--
Tom Christiansen		tchrist at convex.com	convex!tchrist
"With a kernel dive, all things are possible, but it sure makes it hard
 to look at yourself in the mirror the next morning."  -me