Bug#43529: debian-policy: mail locking in Debian is _not_ NFS safe
Package: debian-policy
Version: 3.0.1.1
Severity: important
Policy says the following about the locking of mail:
All Debian MUAs and MTAs have to use the `maillock' and `mailunlock'
functions provided by the `liblockfile' packages to lock and unlock
mail boxes. These functions implement a NFS-safe locking mechanism.
(It is ok if MUAs and MTAs don't link against liblockfile but use a
_compatible_ mechanism. Please compare the mechanisms very carefully!)
The problem with this is, that liblockfile is not NFS-safe when the
client machine runs Linux 2.2.*. The cause of this is the following:
liblockfile uses dotlocking only (no fcntl()).
Linux 2.2.* caches files over NFS, so a client may not notice that the
file was changed on the server, which may lead to the problem, that
the client overwrites a mail folder, where the MDA on the server may
have appended a mail just the moment before.
The solution for this problem is to use fcntl(), because Linux 2.2.*
flushes the cache of a file in the moment when it is locked using
fcntl().
But only fcntl() locking is not enough, because Linux 2.0.* doesn't
support this over NFS and then we have no locking over NFS.
The correct solution for this problem is to combine fcntl() and dot
locking.
The problem with combining these two locking types is, that we may run
into a dead lock, if two programs use a different order of the two
locking methods.
The way out here is to _define_ a special order of the two lockings
(either in the policy or in the reference implementation) or to
implement them in a way, which solves dead locks itself (instead of
locking with one mechanism, and then waiting for the 2nd lock to be
established, it could temporarily undo the first lock and try again
both locks after a (random) sleep, so deadlocks are avoided).
I don't know how the different programs (MDAs, MUAs, IMAPd, popd,...)
handle this, but most of them seem to implement locking themselves
instead of using liblockfile. So the problem is, that we have to
change many packages. But this has to be done, because the use of
dotlock only is a bug which causes mail loss.
What's the correct way to solve this problem now? In Bug#43491
(against liblockfile1) I proposed to simply change the reference
implementation (it is broken, because it is not NFS safe as the policy
expects), but the maintainer of liblockfile first wants a list of all
programs with their order of fcntl and dotlock (if both would be
enabled). I personally do not have the time for this investigation,
but I think that this problem has to be fixed before the next release
(which will come with Linux 2.2.*). So maybe someone else wants to
compile this list? Or maybe someone knows what the most often used
order of these locking methods is or wants to define "our" preferred
order?
Ciao
Roland
-- System Information
Debian Release: potato
Kernel Version: Linux spinnaker 2.2.11 #1 Don Aug 19 22:41:08 CEST 1999 i586 unknown
Reply to: