Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!killer!usource!frankb
From: frankb@usource.UUCP (Frank Bicknell)
Newsgroups: comp.unix.questions
Subject: Re: File Write Permission Rules
Summary: setuid trick doesn't work for Xenix
Keywords: file write permission rules
Message-ID: <166@usource.UUCP>
Date: 21 Feb 89 16:22:48 GMT
References: <306@wubios.wustl.edu> <249@ibd.BRL.MIL> <1995@lindy.Stanford.EDU> <85@opus.ATT.COM>
Organization: UniSource, Inc., Sarasota, FL
Lines: 33

In article <85@opus.ATT.COM>, jgy@opus.ATT.COM (John Young) writes:
> In article <23095@conexch.UUCP>, root@conexch.UUCP (Larry Dighera) writes:
> > In article <630@jonlab.UUCP> jon@jonlab.UUCP (Jon H. LaBadie) writes:
> > <I stumbled upon a system with /tmp directory permissions as follows:
> > <	drwsrwxrwx ......
> > <Note the "s". 
> > <[...] namely a meaning for the set user id bit on directories.
> > <Anyone could create files in the directory,
> > <but only the owner of the directory, OR the owner of the individual
> > <files could remove them.
> 
> (note about the Orange County Unix Users Group omitted)
>
> Release 3.2 already supports this feature (only file owner &
> directory owner (and root)) may remove a file.  This is
> implemented using the 't', sticky bit on the directory.  

I tried it on SCO Xenix 2.3.1... neither trick works :( . 
Sounds interesting, though!

Why should this be implemented with the sticky bit, though?
What does whether or not the directory's text image is saved
after execution ( ;) ) have to do with permission to remove a
file?  Setuid bit seems to be the more logical choice.  After
all, you could extend this to the setgid bit, too, right?  Then
anyone in that group could also remove files.




-- 
Frank Bicknell; 1405 Main St, Ste 709; Sarasota, FL 34236-5701
killer!usource!frankb