hmj@uunet.uu.net (Hannu-Matti J{rvinen) (01/18/89)
I can't recall if these problems have been discussed before, but here they are: 1) Sticky bit in directories Sticky bit in directories prevents removing the files in the directory without write privilege to the file and the directory. (Without sticky only directory write permission is needed). But what happens if you use mv to rename files without write protection in a directory with the sticky bit and write permissions? mv happily creates a new link for the file to be renamed, but can't remove the old link. So mv works essentially as ln. BUT: mv does this for directories, too. ln prevents the hard linking of two directories for the superuser only, by mv and sticky bit anybody can do it. But nobody can remove the created link, not even the superuser. Further, fsck can remove such links, but any time it finds one during boot, the boot will fail because of an "unexpected inconsistency". So I classify this as a bug in mv-command, which do not check beforehand all the permissions needed to do the job. 2) ld -e (SunOs 4.0.1) ld -Bstatic /usr/lib/crt0.o test.o -lc will produce static linking and result shared executables. After several experiments ld -e start -Bstatic etc. was found to make static linking and result to not shared executables. Nothing in the man page of ld tells me, why option -e has this kind of effect. -e implies -Bsymbolic, but ld -Bsymbolic -Bstatic produces shared executable, so there IS something -e does but man doesn't know about. Hannu-Matti Jarvinen, Tampere University of Technology, Finland hmj@tut.fi, hmj@tut.uucp, hmj@tut.funet (tut.ARPA is not the same computer). [[ I do not fully understand your problem #1. I was not able to recreate it on a 4.0.1 system. Have you confirmed that this is a problem? If so, can you please provide a series of commands that will recreate it? "mv" used to work by linking and unlinking, but it no longer does. It uses the "rename" system call. So I don't see how the problem as you have described it could exist. Also, the "unlink" system call will let the super user unlink directories, even if there are still files in that directory. So I believe that, even if one could create an additional link to a directory, the super user can still remove it. I tried recreating the situation you described in (1), but I could not get it to behave the way you said it does. But I've been wrong before.... --wnl ]]
dik@uunet.uu.net (01/31/89)
mcvax!tut.fi!hmj@uunet.uu.net (Hannu-Matti J{rvinen) writes: >Sticky bit in directories prevents removing the files in the directory >without write privilege to the file and the directory....But what happens >if you use mv to rename files without write protection in a directory >with the sticky bit and write permissions?... I assume you use SunOs 3.4 or 3.5 I have the same problem. This problem also occured on a Gould PN900 running UTX 2.03. It allowed two conspiring users to create loops in the file system. My guess is that it is early 4.3 BSD code, our vanilla 4.3 Vax doesn't have the problem. Another problem I have is that ordinary users can't switch on sticky bits on their directories. (I rather like this bug, I must admit considering the above) >....... So I believe that, even if one could create an additional link >to a directory, the super user can still remove it....--wnl ]] In SunOs 3.x NOONE is allowed to remove hardlinks to directory. Unlink(2) returns 'Not Owner', even when called as superuser. So you can only zap (clri/fsck/reboot) a directory-inode with more than one link other than '.' and various '..' entries. [[ Yeah, I didn't think that sounded right when I came across it. But that's what the documentation says! --wnl ]] Casper H.S. Dik University of Amsterdam | dik@uva.uucp The Netherlands | ...!uunet!mcvax!uva!dik