[ On Wed, December 4, 1996 at 14:53:24 (-0800), Curt Sampson wrote: ]
> Subject: Re: Mail and locking
>
> Dot locking, to be portable, can't have any way of removing stale
> locks. Some popular packages do seem to attempt to remove stale
> locks. Others don't. Therefore these programs just aren't interoperable,
> period, and you're deluding yourself if you think they are.

Well, you can't guarantee that stale locks can be removed, but it is
trival to *extend* the original dot locking to support optional ability
for stale lock removal.

> I'm suggesting 1755 for /var/mail.

The sticky bit is redundant in that case.

If I can possibly use set-group-id mailbox access, I prefer 771.

> Umm...how on earth is a process supposed to create its lockfile if you
> turn off the sticky bit? Or are you proposing to go out and modify mail
> programs to make them run suid or sgid?

Creating and deleting lock files are not the problem if you turn off the
sticky bit.  The problem there is avoiding denial of service attacks.

But, as you've already guessed I prefer to use set-group-id programs to
control access to the mailbox spool files.

At least one common mailbox reader (eg. imapd, popd, movemail) must be
run setgid.

> You do want them to run sgid. Ok. I give up right here. Once again
> we seem to have quite differering ideas of security. Not to mention
> `simplicity.'

A unique, member-less group owner for the spool file simplifies the
security model to no end, reducing risks left right and centre.

Setuid-root delivery, as it is now, complicates things far more than
necessary and greatly increases risk.

> Oh, and I enjoyed your description of how to fix a broken mail
> file. Yet another new definition of K.I.S.S., I see.

What can be simpler than copying your precious, but broken, mailbox
spool file to a private place and then causing it to be safely truncated
to allow ongoing deliveries of new good mail by the MTA?  You don't even
have to be superuser to do this safely with the appropriate support
program, such as movemail.

Of course I rarely run systems in such a way that they ever get the
chance to corrupt mailbox files....  I can't recall having to fix a
broken mailbox even on a system with just under 4,000 busy mailboxes.

-- 
							Greg A. Woods

+1 416 443-1734			VE3TCP			robohack!woods
Planix, Inc. <woods@planix.com>; Secrets Of The Weird <woods@weird.com>