Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!husc6!mit-eddie!genrad!decvax!decwrl!pyramid!ncc!lyndon
From: lyndon@ncc.UUCP (Lyndon Nerenberg)
Newsgroups: comp.unix.wizards
Subject: Re: set[ug]id and sticy bits on dirs (was Re: symbolic links are a botch)
Message-ID: <1465@ncc.UUCP>
Date: Sun, 21-Jun-87 17:07:53 EDT
Article-I.D.: ncc.1465
Posted: Sun Jun 21 17:07:53 1987
Date-Received: Tue, 23-Jun-87 00:45:14 EDT
References: <7879@brl-adm.ARPA> <2211@bunker.UUCP> <1715@munnari.oz> <13901@teknowledge-vaxc.ARPA>
Organization: Nexus Computing Corp.,  Edmonton, AB
Lines: 14
Keywords: HUH?
Summary: Here's an idea for the sticky bit

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