Policy: Mail folder creation (Re: Debian mutt package)
[I'm branching this off from a private discussion between myself and
the Debian maintainer of Mutt. Please keep my address on the CC
header as I am not subscribed to debian-devel.]
On Mon, Dec 07, 1998 at 09:21:07PM +0100, Marco d'Itri wrote:
> 30433 mutt: Mutt doesn't create the user's mail file as dictated by
> policy manual
Frankly, I'm considering this requirement serious brain-damage in
the policy manual.
IMHO, MUAs should _never_ _ever_ remove the user's mail spool file,
and the policy manual should forbid that behaviour instead of
allowing it.
The reason for this is simple: From a least-privilege point of view,
the one and only privileged operation a MUA ever needs to perform is
locking and unlocking the spool file. This can nicely be put into
an external program, as mutt demostrates. Removing or creating the
user's spool file is an additional and unnecessary privileged
operation in a configuration like Debian's. It's a security breach
on systems with a mode 1777 mail spool.
Thus, I'd suggest the mail spool file is created by the useradd or
similar programs upon account creation. For robustness reasons,
M_D_As such as procmail and deliver should be required to re-create
it when it doesn't exist, and required MUA behaviour should be as I
wrote above.
(Adding re-creation abilities to mutt would actually mean that we'd
have to make mutt sgid mail again. This is not an option as we do
have the privileged helper program for dotlocking[1]. If Debian
insists of having mutt re-create the mail spool file, you'll have to
create an external program and a shell wrapper to do this.)
tlr, upstream mutt maintainer.
[1] If liblockfile is doing dotlocking (I suppose so), using
mutt_dotlock for the privileged operations may be an interesting
option for Debian.
--
Thomas Roessler · 74a353cc0b19 · dg1ktr · http://home.pages.de/~roessler/
2048/CE6AC6C1 · 4E 04 F0 BC 72 FF 14 23 44 85 D1 A1 3B B0 73 C1
Reply to: