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:
    FEATURE(local_procmail)
    MAILER(procmail)

/etc/sendmail.cf has:
    Mprocmail,  P=/usr/bin/procmail,      ...

).

Procmail as configured on Redhat Linux uses dotlocking and fcntl (procmail -v
returns:
    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
configurables:
    -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.

            Regards,
            Jon Bayh
            jon_g_bayh



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


How reproducible:
Always

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: