Path: utzoo!attcan!uunet!snorkelwacker.mit.edu!apple!usc!cs.utexas.edu!yale!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.unix.internals
Subject: Re: non-superuser chown(2)s considered harmful
Message-ID: <2461:Dec1202:11:0490@kramden.acf.nyu.edu>
Date: 12 Dec 90 02:11:04 GMT
References: <18792@rpp386.cactus.org> <2800:Dec1001:29:4890@kramden.acf.nyu.edu> <1990Dec10.143716.26999@mp.cs.niu.edu>
Organization: IR
Lines: 20

In article <1990Dec10.143716.26999@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes:
> In article <2800:Dec1001:29:4890@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
> >Exactly. This is why several people have been arguing for chown() to
> >work between current and effective uids. Does chown() have any other
> >reasonable use?
>  A great idea.  Just look at the flexibility it will provide creators of
> trojan horse programs.

That's a silly objection. It won't provide any extra flexibility, since
a program with access to another uid can always find every link to a
file, read the data, remove the links, and put in new links to a new
file under the other uid with the same data. The only time this doesn't
work is when the parent directory is not owned by either uid, but what's
the difference between ``vee haff destroyed zee enemy'' and ``vee haff
utterly destroyed zee enemy''? Trojan Horses are deadly in any case.

chown() between uid and euid will improve security for lots of system
programs without introducing any noticeable security holes.

---Dan