Red Hat Bugzilla – Bug 64001
mutt does not correctly dotlock mailbox; race condition can cause corruption.
Last modified: 2014-03-16 22:27:12 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.61 [en] (X11; U; Linux 2.2.12-20 i686)
Description of problem:
It appears that there is a bug in the locking done in the Redhat Linux
version of mutt, as it comes installed on the system, from 6.1 - 7.2.
This might apply to other releases as well---I don't have access to check.
Redhat comes with sendmail configured to use /usr/bin/procmail as the
delivery agent. (/etc/sendmail.mc has:
Mprocmail, P=/usr/bin/procmail, ...
Procmail as configured on Redhat Linux uses dotlocking and fcntl (procmail -v
Locking strategies: dotlocking, fcntl()
Procmail apparently uses /usr/bin/lockfile to do locking of
/var/spool/mail/$USER. As nearly as I can tell from the source code for
procmail and lockfile, /usr/bin/lockfile locks the user's mailbox by
doing an exclusive create open of a temporary file in /var/spool/mail,
and an atomic link to /var/spool/mail/$USER.lock. It apparently
does _not_ do an fcntl on /var/spool/mail/$USER to guard access to the file,
relying on the .lock file to guard access.
mutt, as compiled on Redhat distributions, has the following locking
-USE_DOTLOCK +USE_FCNTL -USE_FLOCK
(I think the intention was that only one of three different locking methods
would be used. The correct approach should be DOTLOCK + (FCNTL | FLOCK) ).
When I force a lock on my /var/spool/mail/$USER mailbox using "lockfile -ml",
and then send a message to $USER, the message is correctly held pending
until the lock is released. However, during the period that the lock is
still held, I can start mutt up, delete a message, and exit mutt, with the
message actually being deleted from the mailbox file.
Looking at the strace output on mutt as it is compiled on Redhat 6.1, I can
see the /var/spool/mail/$USER file opened for RW, an fcntl with F_SETLK
is done on it, it is read and truncated and closed. But no link to a
/var/spool/mail/$USER.lock file is done.
When I compile mutt myself, with +USE_DOTLOCK enabled by default, the
"mutt_dotlock" and "lockfile" correctly block each other from holding the
lock simultaneously, and "lockfile" prevents the locally compiled mutt from
writing the /var/spool/mail/$USER file.
So, this looks like a bug in the way that mutt is configured and compiled
on Redhat, unless I'm misunderstanding something. I'm submitting this as
a high severity bug due to the possibility of data corruption from the
race condition on the mail file.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. lockfile -ml
2. Start mutt. Delete a message from mailbox. Quit mutt.
3. Check mailbox. Message was deleted during a period when it should not have
been possible to do so.
4. lockfile -mu
Actual Results: Message was deleted from mailbox, demonstrating race condition
Expected Results: Mutt should have been blocked from deleting message due to
presence of lock file.
mutt is configured to use fcntl locking, as is procmail; neither should use