[ On Wed, December 4, 1996 at 07:35:11 (-0800), Curt Sampson wrote: ]
> Subject: Re: Mail and locking
>
> There's a reasonable argument to be made that honouring both locking
> protocols, rather than forcing people to modify the source code of
> random mail packages, is the simpler option.

All common mail packages *must* implement dot_locking in order to be
portably used on random systems.  Most I know of do so, though as you
pointed out they don't all do so correctly.

> > The only known disadvantage of dot-locking (other than the fact that it
> > requires a setuid or setgid process with write access to the spool
> > directory)
> 
> As if that isn't a major disadvantage in itself. It's open to denial
> of service attacks on new accounts, for a start.

Excuse me?  How?  I'd expect /var/mail to be either mode 711 at best, or
1775 at worst.  In general 1777 (or worse 777) is, of course, insanity.

What it does permit is denial of service attacks if you can somehow
create lock files for another user's mailbox.  This can be prevented if
the spool directory does not have the sticky bit set and authorized mail
processes just blow away locks that are owned by someone other than the
mailman or the mailbox owner.

If the local delivery and mail-pickup processes are setgid to the unique
member-less group which owns and has write permission on /var/mail, and
the system supports the POSIX notion of giving away files on quota-less
filesystems, and /var/mail is on such a filesystem, then life with
mailers can become very mundane and routine with few risks to anyone.
Of course it also helps if the delivery process can enforce local policy
too, such as maximum mailbox sizes with decent bounce explanations; and
if there's an ftruncate() system call....  If you can't give away a
file on a given system, then the only change to this schema is that
mailboxes must be created by root instead of by the mailman, and must
never be removed.

Maybe we can blame all the CERT sendmail advisories on the silly need to
support the filesystem quotas so rarely used in practice.  [0.5 ;-)]

> However, I've taken the opportunity to look through some source
> code, and it's becoming more and more evident that dot locking is
> not in the slightest bit reliable, because it appears to be done
> in different ways by different people.

Please be very careful how you define "reliable" here.  It is extremely
reliable when the correct algorithm is implemented properly.  What
you're saying is only that many people cannot write correct code the
first few times around.  There's nothing new in that!

> And what is your preferred method of fixing a broken mail file?
> Mail files do break, and you have to have have some way of doing
> this.

Well, normally I copy it somewhere private first, and if I happen to
have something like shlock or newslock that will let me create a valid
lock file I'll truncate the original spool file too, or I may do it by
hand.  If necessary I'll shut down the mailer for a moment, make sure
the user's not going to try to read mail, truncate the original spool
file, and then restart the mailer.  If I have no way of creating a sure
lock I'll just hand the "fixed" mail file to the user in their home
directory, etc., or I'll again shut down the mailer and append it to
their spool file.

I would never ever ever edit a live spool file.

-- 
							Greg A. Woods

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