Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!columbia!rutgers!sri-spam!mordor!lll-tis!ptsfa!ihnp4!occrsh!occrsh.ATT.COM!tiger.UUCP!authorplaceholder
From: rjd@tiger.UUCP
Newsgroups: comp.unix.wizards
Subject: Re: set[ug]id and sticy bits on dir
Message-ID: <142700006@tiger.UUCP>
Date: Tue, 23-Jun-87 09:46:00 EDT
Article-I.D.: tiger.142700006
Posted: Tue Jun 23 09:46:00 1987
Date-Received: Fri, 26-Jun-87 06:31:35 EDT
References: <1465@ncc.UUCP>
Lines: 25
Nf-ID: #R:ncc.UUCP:-146500:tiger.UUCP:142700006:000:1248
Nf-From: tiger.UUCP!rjd    Jun 23 08:46:00 1987


> > OK, so what meanings attach to set[ug]id and sticky bits when applied
> > to the mode of a directory or the mode of a device file?
> 
> One system I maintained (running a Unisoft port) used the sticky bit
> on a 777 directory to mean "anyone can create a file here, but only
> the owner can delete it". This was used on /tmp and /usr/tmp.
> 
> This would be useful in a number of situations. On our MiniFrame,
> /usr/spool/uucp must be 777 in order for cu(1) to create and
> unlink the lock files for the port, despite the fact that the
> damn thing runs suid to root :-(  Therefore, it is possible for
> anyone to bounce in and type "rm -f" ...  Having the sticky bit
> mod available for this directory would go a long ways towards
> fixing this rather blatent hole.

  Not to mention /usr/spool/uucppublic files end up readable by the world
normally and owned by uucp.  It seems to me that the final path to a person's
received files and the files themselves should be owned by him and readable
by him only.  This does not require a setuid(), just a chmod followed by a
chown (at least in shell, I have not used the C routines enough to know off the
top of my head, and of course this would be a modification to the uucico C
source).

Randy