Re: Mail delivery privileges (was: Solaris /usr/bin/mailx exploit)

[Olaf Kirch <okir () caldera de>]

On Fri, May 18, 2001 at 11:18:51AM -0400, Wietse Venema wrote:
> 2 - Lock file management. If mail is delivered as nobody:mail, then
> /var/mail/username.lock files are owned by user nobody.  This means

If you insist on using lock files for synchronization, that is. If you
make sure all your MUAs and your MTA do proper flock locking, you get
synchronization without the privilege issues surrounding lock files. That
was in fact the least common denominator I found when I investigated
something like 20 Unix mail software packages about three years ago
(The major exception being wu-imap that's doing flock locking as an
afterthought to dotlocking, and ignores any errors returned by flock).

The only functionality you lose with flock is the ability to remotely
mount your mail spool via NFS; but you shouldn't be doing this anyway.

There's a fourth aspect of mail delivery privilege which is creation of
the user's mailbox. The MTA or its helper programs need to be able to
create the mbox if it isn't there; and may you also have to accomdate
people putting procmail in their .forward files.

So far, the .maildir concept is the best approach I've seen to solve
the issues surrounding delivery to the user's mailbox because it is the
only one AFAICT where you only cross privilege boundaries "downward"
i.e. from a system service to a user service, and never the other way
round (e.g. setgid mail helpers for creating lock files).

Olaf
-- 
Olaf Kirch         |  --- o --- Nous sommes du soleil we love when we play
okir () monad swb de  |    / | \   sol.dhoop.naytheet.ah kin.ir.samse.qurax
okir () caldera de    +-------------------- Why Not?! -----------------------
         UNIX, n.: Spanish manufacturer of fire extinguishers.