Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!chinacat!sequoia!rpp386!jfh
From: jfh@rpp386.cactus.org (John F Haugh II)
Newsgroups: comp.unix.internals
Subject: Re: non-superuser chown(2)s considered harmful
Message-ID: <18792@rpp386.cactus.org>
Date: 8 Dec 90 02:13:05 GMT
References: <1990Dec6.005358.6336@dg-rtp.dg.com> <109958@convex.convex.com> <18786@rpp386.cactus.org> <1990Dec7.171501.18028@mp.cs.niu.edu>
Reply-To: jfh@rpp386.cactus.org (John F Haugh II)
Organization: Lone Star Cafe and BBS Service
Lines: 33
X-Clever-Slogan: Recycle or Die.

In article <1990Dec7.171501.18028@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes:
> What do you mean by 'support chown()'.  Should another field be added
>to the 'inode' specifying the 'real owner' to be used for permissions,
>and chown() by other than root preserves this 'real owner' field.  This is
>adding too much complexity.  Disallowing non-root access to chown() is
>simpler, more effective, and safer.

The context of the thread was that chown() messes up the quota mechanism,
and is therefore evil.  This is the common excuse, and is often used as
the justification for BSD not supporting non-root chown().

However, this is silly.  If the system can properly maintain quotas
with open/creat and unlink calls being made, there is no reason it
cannot properly maintain quotas with chown() system calls.

Other arguments are that you shouldn't be able to give someone a
file, for some mystery reason, where "some mystery reason" often comes
down to users who circumvent their quota by changing the ownership to
someone else, and maintaining read/write access to the file after
giving it away.  This is an administrative problem, and as such the
policy should be administrative.

The result of making a system call "root-only" is that any application
which might have a legitimate need to execute that function must be
set-uid to root in order to perform that now privileged operation.
For example, if all the unallocated TTY devices were owned by "uucp",
all the applications which deal with TTY devices would only have to
be set-UID to "uucp".  Unfortunately, if you have an application that
wants to change the ownership to the user, such as cu, you must now
make cu set-UID to "root".
-- 
John F. Haugh II                             UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 832-8832                           Domain: jfh@rpp386.cactus.org