bernsten@phoenix.princeton.edu (Dan Bernstein) (11/08/88)
Reply-to: bernsten@phoenix.princeton.edu (Dan Bernstein) On our system, /usr/spool/mail and /tmp (among others) are protected as rwxrwxrwt. Here the t is the ``sticky bit,'' which according to our superuser and other sources is supposed to protect files from other users, despite the writability of the directory. Indeed, one cannot rm a file in the directory owned by another userid or do much else to it. However, we have determined that someone could destroy another person's files by moving a file of his own over it. For example, shmoe could delete fooper's mail by touch /usr/spool/mail/foo mv /usr/spool/mail/foo /usr/spool/mail/fooper rm /usr/spool/mail/fooper The touch works because the directory is writable, the mv works because mv apparently ignores the sticky bit, and the rm works because the directory is writable and fooper suddenly belongs to shmoe. It seems to me that this is a mv bug. More insidiously, one user could replace another's mail with any set of damaging messages, or perhaps change a vi temporary file. Our superuser's comment to hearing of this was ``Oh my God, you're right!'' and he is now recompiling the system. Questions: (1) Is this just our system (DEC VAX 8700, Ultrix 2.0 I believe, which is basically System V with BSD 4.2 or 3 enhancements) or is it a general problem with ULTRIX? (2) Is this documented? (3) Assuming not, is there any reason it isn't a bug? (4) I realize that the problem with /usr/spool/mail can be solved by making it rwxr-xr-x, because the mail daemon is smart enough to still be able to create a file in there. But this doesn't work for /tmp. Can someone provide a set of workarounds that really work or, better, fixes for the system code? Hey, if you're reading this, I'll bet you ten to one that someone has already followed up on it. So please mark this as unread, read to the end of the newsgroup, and then answer only if necessary. ---Dan Bernstein, bernsten@phoenix.princeton.edu