The sad state of locking -> it almost works

[Sam Roberts]

Hi Sergey,

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. That debian
guy, for example, isn't getting any locking that the other mail tools on
linux will respect. 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 (both of which happened to me, and sidetracked me from
sieve into working on the locker_t).

I think we have requirements confusion, and we are working at cross
purposes.

Stepping back, there are two kinds of systems, dot locking, and kernel
locking. You don't get to choose, unless ALL the tools are yours. So, a
wholly GNU mailutils system could chose either scheme, if you have to
interoperate, though, you have to do the way other programs do.

I only use QNX and Linux, and they use dotlocking, and their mail spools
aren't writeable except by group mail, so thats what i've been thinking
about.


-- dotlocking systems --

  Programs that read the spool must be setgid (a bad idea) or must use an
  external program to do the dotlocking. Servers start as root, and setgid,
  so they can do the dotlocking using their effective group id.

  Only with an external setgid dotlocker can non-setgid programs lock a Linux
  mailspool, AFAIK.

  Cases in point: procmail which is setgid, apparently, and mutt, which uses
  a setgid mutt_dotlock.

-- kernel systems --

  Don't need any special priviledges to do kernel locking.


So, requirements and proposals:

1 - we need to know whether to use dot or kernel locks.

I propose that one of MU_LOCKER_KERNEL or MU_LOCKER_DOT must
be set if you want to lock something (i.e, its not a NULL locker).

This can be set in /etc/mailutils.rc as:

:mailbox --mail-spool=/my/spool --lock-flags=[DK]

Default should likely be D, unless there's a configure option, or we
guess something else, or....


2 - if dotlocking, we may have to call an external locker

I propose that locker_lock(), if it needs to apply a lock, checks
if it has write access to the directory. If it does, it directly
locks, if not, it uses an external locker.

If it fails, if returns an error.

3 - if kernel locking, just kernel lock

4 - we need to be able to not lock on read, if somebody is willing, for
    performance reasons

Alain and I talked about this a while. He convinced me that performance cost
of dotlocking for utilities like frm is prohibitive. I still think it should
be possible to read a mailbox and know its not going to change under you.

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.



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?

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.


The pieces are all there, now that lock flags are configurable, and
there's an external dotlock utility and mode, we just have to put
them together in a way that works.

Cheers,
Sam

-- 
Sam Roberts <address@hidden> (Vivez sans temps mort!)