> local delivery agent(s). After all that's all you've got with "*.lock" > files, since they too are only advisory locks. Putting them into the > kernel simply makes it possible to eliminate the risk of a mode 01777 > spool directory. (The risk is already quite low of course if you > pre-create all mailbox spool files, and especially if you write careful > lock validation code in the local delivery agent. Kernel locks simply > make the code for safe local delivery less complex.) Not quite. Any scheme which relies on pre-existing mailboxes would also have to make sure that the owner of the mailbox cannot remove it. This means not only standard MUAs but also "rm", "mv"[1], accidental mistakes or user-installed MUAs. As I see it this is pretty much impossible to guarantee. So reliance on pre-existing mailboxes is inherently unsafe because it relies on assumptions which can not be guaranteed, regardless of useradd programs etc. Another reason why mail delivery into the home directory, although requiring root privileges (rsp. setuid capability), causes less headache overall. Olaf [1] Didn't you ever filter out the few good messages out of a 10MB mailbox full of looped bounces with sed after moving it into your home and then remove the whole junk at once instead of waiting for the MUA to do several minutes of filtering? I did.
This archive was generated by hypermail 2b30 : Sat May 19 2001 - 14:37:43 PDT