Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!execu!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: <18796@rpp386.cactus.org>
Date: 9 Dec 90 21:03:50 GMT
References: <18786@rpp386.cactus.org> <1990Dec7.171501.18028@mp.cs.niu.edu> <18792@rpp386.cactus.org> <110075@convex.convex.com>
Reply-To: jfh@rpp386.cactus.org (John F Haugh II)
Organization: Lone Star Cafe and BBS Service
Lines: 19
X-Clever-Slogan: Recycle or Die.

In article <110075@convex.convex.com> tchrist@convex.COM (Tom Christiansen) writes:
>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.

Yes, and this is a much better solution - restrict chown() to be between
the real and effective UIDs, rather that completely out the window.  It
does solve the problem of privileged subsystems (such as CU and UUCP)
being able to flip a file over to another user and back again.

However, in a co-operative environment (such as commercial installations)
there is quite a bit of file-sharing going on in a very ad hoc fashion.
User's should not be forced to contact an administrator, or perform file
access mode mumbo-jumbo to give a file away.  Why FIPS went with chown()
being restricted is a mystery ...
-- 
John F. Haugh II                             UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 832-8832                           Domain: jfh@rpp386.cactus.org