Mail semantics: mail group, permissions, MTA/MDA suid/sgid and the like

[Axel Thimm]

Hi,

Red Hat/Fedora mail delivery is not using the sticky-bit method, but
works with the mail group idiom.

Does anyone have a good design document of the latter somewhere? I
couldn't find anything detailed on the net and some parts I had to try
find out experimentally (which, if I'm triggering a bug, may be
wrong). So, I'm writing a few bits together and will make that a wiki
page out of it, when some open questions are filled out.

OK, the basic given is that /var/mail is 0775 root:mail which means
that only root and group mail can write into it, which includes
dotlocking. The system mbox are owned by the user and are group
mail. Furthermore the blessed locking mechanisms are fcntl and
dotlock.

Questions:

a) Does every MDA and MUA need to do both locking mechanisms or is
   dotlocking the fallback to fcntl? The latter would be an issue, so
   it should probably be both for every MDA/MUA.

b) What are the proper permissions for the system mboxes 0600 or 0660?
   The latter implies that group mail can do nasty things.

c) Under which group should an MDA run as?

If the system mbox has not been created yet, it needs to be running
   as group mail. Also if dotlocking is required the MDA again needs
   to be running as group mail, or needs to have an external sgid
   dotlocking program (like procmail does).

If the MDA allows external programs like .forward/procmail/maildrop
   the user can effectively become group mail whenever he wants. If the
   system mboxes are mode 0660 this is devastating.

I think the answers are

a) both
b) 0600
c) <user>:mail

In that case any MTA/MDA using 0660 is broken which includes at least exim.

[Bill Nottingham]

Axel Thimm ([e-mail]) said:
> a) Does every MDA and MUA need to do both locking mechanisms or is
>    dotlocking the fallback to fcntl? The latter would be an issue, so
>    it should probably be both for every MDA/MUA.

Short answer is use fcntl or die.

Bill

[Axel Thimm]

On Fri, Mar 30, 2007 at 01:03:31AM -0400, Bill Nottingham wrote:
> Axel Thimm ([e-mail]) said:
> > a) Does every MDA and MUA need to do both locking mechanisms or is
> >    dotlocking the fallback to fcntl? The latter would be an issue, so
> >    it should probably be both for every MDA/MUA.
>
> Short answer is use fcntl or die.

OK, then we should remove current dotlock functionality from MTA/MDAs?
I'm fine with that, it just needs to be a global and wide known policy
so that MTA1 doesn't dotlock while MDA5 fcntl-locks and both think
they own the mbox.

[Bill Nottingham]

Axel Thimm ([e-mail]) said:
> > > a) Does every MDA and MUA need to do both locking mechanisms or is
> > >    dotlocking the fallback to fcntl? The latter would be an issue, so
> > >    it should probably be both for every MDA/MUA.
> >
> > Short answer is use fcntl or die.
>
> OK, then we should remove current dotlock functionality from MTA/MDAs?
> I'm fine with that, it just needs to be a global and wide known policy
> so that MTA1 doesn't dotlock while MDA5 fcntl-locks and both think
> they own the mbox.

The long-standing policy in Core was to unly use fcntl - it's the
one thing that should be supported by all clients, stands a chance
of working over NFS, etc. So, explicitly codifying this makes sense.

Bill