mkhaw@teknowledge-vaxc.UUCP (06/21/87)
In article <1715@munnari.oz> kre@munnari.oz (Robert Elz) writes: (with regard to mode bits on a symbolic link) >access its value in a path lookup. I have ideas for the set[ug]id >bits, and I'm sure a meaning for sticky will come to me! I would like 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? Mike Khaw -- internet: mkhaw@teknowledge-vaxc.arpa usenet: {hplabs|sun|ucbvax|decwrl|sri-unix}!mkhaw%teknowledge-vaxc.arpa USnail: Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303
lyndon@ncc.UUCP (Lyndon Nerenberg) (06/22/87)
> 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.