Bug 64001
| Summary: | mutt does not correctly dotlock mailbox; race condition can cause corruption. | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Need Real Name <jon_g_bayh> |
| Component: | mutt | Assignee: | Bill Nottingham <notting> |
| Status: | CLOSED NOTABUG | QA Contact: | |
| Severity: | high | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.2 | CC: | rvokal |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i586 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2002-04-23 17:06:04 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
mutt is configured to use fcntl locking, as is procmail; neither should use lockfiles. |
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: