diamant@hpfclp.SDE.HP.COM (John Diamant) (07/12/88)
> this is a bug in the Ultrix-sendmail. You can fix it by setting the mode > of '/usr/spool/mail' to 1777 (don't forget the sticky bit, or everyone > can remove your mailbox!). Would you care to explain that item about the sticky bit? I always that the sticky bit was merely an efficiency hack. Are you saying that it actually changes the security of the running program? How? John Diamant Software Development Environments Hewlett-Packard Co. ARPA Internet: diamant@hpfclp.sde.hp.com Fort Collins, CO UUCP: {hplabs,hpfcla}!hpfclp!diamant
lyndon@ncc.Nexus.CA (Lyndon Nerenberg) (07/15/88)
In article <1410006@hpfclp.SDE.HP.COM> diamant@hpfclp.SDE.HP.COM (John Diamant) writes: >Would you care to explain that item about the sticky bit? I always that the >sticky bit was merely an efficiency hack. Are you saying that it actually >changes the security of the running program? How? In some BSD implementations, setting the sticky bit on a directory says that (if you have the appropriate write permission) you can create a file in that directory, however you have to be the owner of the file in order to remove it. We use this feature in a number of public "spool" directories where we don't want to run an suid program soley for the purpose of protecting files from inadvertant or malicious deletion. [ Where did this "feature" originate, anyway ?? ] -- {alberta,pyramid,uunet}!ncc!lyndon lyndon@Nexus.CA Ain't singin' for Miller...
robert@pvab.UUCP (Robert Claeson) (07/18/88)
In article <10331@ncc.Nexus.CA>, lyndon@ncc.Nexus.CA (Lyndon Nerenberg) writes: > In some BSD implementations, setting the sticky bit on a directory says > that (if you have the appropriate write permission) you can create a > file in that directory, however you have to be the owner of the file > in order to remove it. AT&T has included this feature in their latest release of UNIX System V, Release 3.2. It comes with the sticky bit set as default on /tmp and /usr/tmp.