Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!texsun!convex!convex.COM
From: tchrist@convex.COM (Tom Christiansen)
Newsgroups: comp.unix.internals
Subject: Re: non-superuser chown(2)s considered harmful
Keywords: chown security quota BSD SYSV
Message-ID: <109958@convex.convex.com>
Date: 6 Dec 90 14:38:53 GMT
References: <1990Dec5.135759.12508@noao.edu> <1990Dec6.005358.6336@dg-rtp.dg.com>
Sender: usenet@convex.com
Reply-To: tchrist@convex.COM (Tom Christiansen)
Organization: CONVEX Software Development, Richardson, TX
Lines: 29

In article <1990Dec6.005358.6336@dg-rtp.dg.com> goudreau@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@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