Bug 64001 - mutt does not correctly dotlock mailbox; race condition can cause corruption.
mutt does not correctly dotlock mailbox; race condition can cause corruption.
Product: Red Hat Linux
Classification: Retired
Component: mutt (Show other bugs)
i586 Linux
medium Severity high
: ---
: ---
Assigned To: Bill Nottingham
Depends On:
  Show dependency treegraph
Reported: 2002-04-23 13:05 EDT by Need Real Name
Modified: 2014-03-16 22:27 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-04-23 13:06:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Need Real Name 2002-04-23 13:05:59 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:

/etc/sendmail.cf 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
(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.

            Jon Bayh

Version-Release number of selected component (if applicable):

How reproducible:

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
between mutt
and procmail.

Expected Results:  Mutt should have been blocked from deleting message due to
presence of lock file.

Additional info:
Comment 1 Bill Nottingham 2002-06-12 02:52:47 EDT
mutt is configured to use fcntl locking, as is procmail; neither should use

Note You need to log in before you can comment on or make changes to this bug.