Re: The sad state of locking -> it almost works

[Sergey Poznyakoff]

Hi, 

> that latest batch of changes to the locker doesn't really work. You can't
> silently change from a dot lock to a kernel lock and call it success.  If
> some other program dotlocks it you will both think its locked. 

This is possible, but consider this:

 1. Default Linux /bin/mail uses flock to lock mailbox before writing
    to it.
 2. Widely-used (on GNU/Linux at least) mail.local uses both dot-lock
    and kernel-level locking via flock.
 3. Procmail (again widely used on GNU/Linux) creates dot-lock, but
    uses flock before writing to the mailbox (see locking.c,
    mailfold.c).
 4. Mutt: first applies kernel locking, then creates dot-lock
    if requested (see mx.c).

The overall situation confirms that the widely-used mail programs will
honour kernel locking.

> He won't realize it unless he loses some mail, or
> get suspicious when mail and some other program both have the same mailbox
> open for write

Basing on the above this doesn't seem probable. 

> I only use QNX and Linux, and they use dotlocking, and their mail spools
> aren't writeable except by group mail,

Well, as for Linux this is not quite so. The 'dotlock vs. kernel
locking' situation is described above. Let's try to summarize
the information about mailspool permissions.

I. GNU/Linux:

 (Debian):
   drwxrwsr-x   2 root     mail           18 Mar 28 20:46 /var/mail
 (Slackware)
   drwxrwxrwt   2 root     mail         1024 Apr 11 11:58/var/spool/mail//
 (SuSE)
   drwxrwxrwt   2 root     mail         1024 Apr 11 11:58/var/spool/mail//

II. Solaris/SunOS:
   drwxrwxrwt   3 root     mail         512 Apr  4 17:08 /var/mail

III. FreeBSD
   drwxrwxr-x  2 bin  mail  512 Jun 26  2001 /var/mail/

> So, requirements and proposals:
[..good stuff deleted..]

Seems ok. My proposals are to follow the practice shown by procmail,
mutt and others, that is: use dot-locking and apply kernel-locking
to the mailbox right before writing to it (of course, this applies
only to unix-style mailboxes). 

> We agreed on adding the read/write lock flag back to locker_lock().
> 
>   - kernel locking can use it for rd/wr locks
> 
>   - utilities that wish can set a NO_LOCK_ON_READ flag (or it can
>     be set in --lock-flags), it will do what it sounds like. Read
>     locks will return sucessfully without actually locking.

OK.

> Alain and I talked about this a while. He convinced me that performance cost
> of dotlocking for utilities like frm is prohibitive. 

Agreed.

> I think this covers all the normal cases. You mention that there
> is a third case for imap, a 3rd file location that neither the
> logged in user, nor the mail group has the ability to do locks in.
> 
> Did you mean dotlocks, or kernel locks, or both?

Both, I believe. This happens when a mailbox to be read resides in a
non-writable directory and is non-writable itself. But then, there is
hardly a reason to lock it, is there?

> Is it possible that (4) above solves that? I.e., if they don't have
> access, they shouldn't do an IMAP "select", they should do an
> IMAP "examine", and that should mean that only read-only operations
> are performed on the mailbox. List should list the thing as read-only.

Surely, this will solve the problem with imap4d. 

To summarize:

1. Introducing NO_LOCK_ON_READ solves problem with imap4d.
2. Problem with mail on systems whose mailspool is not world-writable
   may be solved using setuid/setgid dotlock.

However, usual /bin/mail works without creating dotlock files, and
works quite reliably. So, consider my proposition about
compulsory kernel locking.

Regards,
Sergey