rjd@tiger.UUCP (06/23/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. 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
daveb@geac.UUCP (Dave Brown) (06/26/87)
In article <142700006@tiger.UUCP> rjd@tiger.UUCP quotes: >> 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. One can simulate this by writing an "append" program and putting a link in the applicable directory. I published one last winter in mod.sources, so it must be easy (:-)) -- Computer Science | David (Collier-) Brown loses its memory | Geac Computers International Inc. every 6 months | 350 Steelcase Road,Markham, Ontario, -me. | CANADA, L3R 1B3 (416) 475-0525 x3279