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

> Please folks, K.I.S.S.!!!

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.

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

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.

The UofW imap v3 server, for example, expects that the lock is out
of date if it can flock() the lockfile (meaning, no other processes
on the current system have that file open). So we still loose over
NFS. We also loose if any other client out there creates a lock
file but doesn't hold it open while it's working.

The v4 imap server is a bit different; it ignores username.lock
files entirely if it gets EACCESS when it tries to open the file,
assuming that the spool permissions are set up to disallow this
sort of thing. There's another denial of service attack for you;
just `touch /var/mail/foo.lock; chmod 0 /var/mail/foo.lock' to
disable someone's mail locking entirely. Or if this happens by
accident (a badly written MTA delivers as root, with the lockfile
locked as root) there goes your locking.

It's fixed the NFS problem by just checking the ctime on the inode;
if it's older than a certain time, it assumes its out of date. Lord
help you if something else creates a lock file and doesn't update
it every few minutes.

Fortunately, both c-clients use flock as well.

> Anyone crazy enough to run 'vi' on a live spool file deserves to lose
> all their mail....

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.

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.