guy@rlgvax.UUCP (Guy Harris) (02/17/84)
> We run a 4.1bsd system, and have recently been having a discussion > about mailbox protection. One suggestion was that /usr/spool/mail should > be writable only by root. . . . > 2) What other effects (good or bad) are caused by not having > /usr/spool/mail world-writable? Well, the mailbox locking protocol requires the mail reader to be able to create directory entries in /usr/spool/mail, which is a botch and causes the mail readers to spend several seconds trying fruitlessly to lock the mailboxes when entered if /usr/spool/mail isn't world-writable. Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy
thomas@utah-gr.UUCP (Spencer W. Thomas) (02/21/84)
The current mailbox locking scheme S**KS for exactly the reason mentioned by rlgvax!guy -- you can't lock mailboxes when /usr/spool/mail is not writable. Leaving /usr/spool/mail writable is a BIG BIG BIG BIG security hole (write for details, using root login). We changed mail to lock on /tmp. This isn't so good, but it is better. Seems to me that on 4.2, which supports advisory file locking, that the file locking should be used. Once you've moved the locks off of /usr/spool/mail, then you can go ahead and change the mode to 755. =S
jab@uokvax.UUCP (02/23/84)
#R:yale-com:-292600:uokvax:6200020:000:415 uokvax!jab Feb 18 09:18:00 1984 If /usr/spool/mail (/usr/mail on System V) is writable, then people can remove other people's mailboxes. Admittedly, the "sticky directory" idea that is in one of the Berkeley systems (i.e. "+t" on directory means you can only unlink files that you own) helps this. I would hope that people on your system aren't malicious enough to do this, but an accidental "rm -f" in the wrong directory can do wonders. Jeff