On Wed, 4 Dec 1996, Greg A. Woods wrote:

> 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.

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.

> 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.

I'm suggesting 1755 for /var/mail.

> 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.

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?

> 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.

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.'

> 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!

In other words, any algorithm that attempts removal of stale locks
is incorrect. You obviously don't administer any large sites.

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.

cjs

Curt Sampson    cjs@portal.ca		Info at http://www.portal.ca/
Internet Portal Services, Inc.	
Vancouver, BC   (604) 257-9400		De gustibus, aut bene aut nihil.