Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!rpi!bu.edu!snorkelwacker.mit.edu!apple!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
Message-ID: <110075@convex.convex.com>
Date: 8 Dec 90 15:58:55 GMT
References: <18786@rpp386.cactus.org> <1990Dec7.171501.18028@mp.cs.niu.edu> <18792@rpp386.cactus.org>
Sender: usenet@convex.com
Reply-To: tchrist@convex.COM (Tom Christiansen)
Organization: CONVEX Software Development, Richardson, TX
Lines: 41

In article <18792@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes:
>The context of the thread was that chown() messes up the quota mechanism,
>and is therefore evil.  

That's one reason.  I think there are others.  Being able to make an 
arbitrary file belong to another user seems almost as bad as making
an arbitrary file owned by you.  It runs against my intuitive feel
for what the ownership of a file really is.  If I want to know whose
file this is, should I mail every user on the system, or should I 
examine the owner field in the inode?  Some programs rely on the
ownership of a file to make inferences about what is a safe and
reasonable operation vis-a-vis security.  I'm not ready to accept
that programs that do this a "just stupid broken BSD hacks" as the
ATT folks maintain.  It also bother me that I can create files that
I can no longer unlink or even access without superuser assistance.

>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".

Yes, there is that unfortunate consequence.  No one ever said the
all-or-nothing way of doing superuser privileges on UNIX was the optimal
route.  That's why a lot of us have written interfaces to provide limited
superuser access.  See the sudo.c program in Evi Nemeth's sysadmin book,
or read about the op program I describe in the LISA-3 proceedings.

If you could switch a file's ownership between real and effective uid's,
this wouldn't be a problem.  Since a process can always cp a file, at
which time it will be owned by whichever ID was active at the time, I
don't see why that can't be allowed.

--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