Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!seismo!rochester!pt.cs.cmu.edu!sei.cmu.edu!pdb
From: pdb@sei.cmu.edu.UUCP
Newsgroups: comp.unix.wizards,comp.unix.questions
Subject: Re: UNIX file setuid sucurity hole?
Message-ID: <695@aw.sei.cmu.edu.sei.cmu.edu>
Date: Fri, 13-Mar-87 03:04:21 EST
Article-I.D.: aw.695
Posted: Fri Mar 13 03:04:21 1987
Date-Received: Sat, 14-Mar-87 02:11:21 EST
References: <2168@ncoast.UUCP>
Sender: netnews@sei.cmu.edu
Reply-To: pdb@sei.cmu.edu.UUCP (Pat Barron)
Distribution: world
Organization: Carnegie-Mellon University, SEI, Pgh, Pa
Lines: 25
Xref: utgpu comp.unix.wizards:1355 comp.unix.questions:1349

In article <2168@ncoast.UUCP> robertd@ncoast.UUCP (Robert DeMarco) writes:
>	It just accured to me that, 
>thanks to the chown command and "setuid
>to owner when executing this C program"
>that no ones file is realy safe.
>
...
>	How can you protect against
>this?
>

Easy.  Remember, unless you are the super-user, you can't use the chown command
at all, not even to chown one of your own files.  There are a number of reasons
for that; the problem you pointed out is one of them.  As it pointed out in the
original Version 7 programmer's manual, if you were on a system with disk space
accounting, if just anyone could chown stuff, you could subvert the accounting
system.

Of course, if you are running on a system which does allow random users to
use chown (I've never heard of such a beastie, but just for the sake of
argument...), I'd have have chown clear the 6000 bits of a file's protection
as part of the chown process (and, of course, you couldn't reset them, since
you can't chmod a file you don't own....)

--Pat.