239013 - Movemail on *BSD should use flock(2) for locking mail file

Status: RESOLVED DUPLICATE of bug 384774

(MailNews Core :: Movemail, defect)

Description

[Archie Cobbs]

User-Agent:       Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040312
Build Identifier: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040312

BSD machines use flock(2) system call to lock mail files,
not xxx.lock files. Movemail will avoid corrupting the
mail file if it locks is consistently with other daemons
running on the system.

Reproducible: Didn't try
Steps to Reproduce:
1.
2.
3.




Attached a patch that implements this change.
Needs to be configured during build time of course.

Comment 1

[Archie Cobbs]

Attachment: Patch to workaround this bug

Comment 2

[Roland Mainz]

At least Solaris has a "standard" function for that purpose:
-- snip --
User Mailbox Library Functions                    maillock(3MAIL)

NAME
     maillock,  mailunlock,  touchlock  -  functions  to   manage
     lockfile(s) for user's mailbox

SYNOPSIS
     cc [ _f_l_a_g ... ] _f_i_l_e ... -lmail [ _l_i_b_r_a_r_y ...
]
     #include <maillock.h>

     int maillock(const char *user, int retrycnt);

     void mailunlock(void);

     void touchlock(void);

DESCRIPTION
     The maillock() function attempts to create  a  lockfile  for
     the  user's  mailfile.  If a lockfile already exists, and it
     has not been modified in the last 5 minutes, maillock() will
     remove the lockfile and set its own lockfile.

     It is crucial that programs locking mail files refresh their
     locks   at  least  every three minutes to maintain the lock.
     Refresh the lockfile by  calling  the  touchlock()  function
     with no arguments.

     The algorithm used to determine  the  age  of  the  lockfile
     takes into account clock drift between machines using a net-
     work file system. A zero is written  into  the  lockfile  so
     that  the  lock  will   be  respected by systems running the
     standard version of System V.

     If the lockfile has been modified in the last 5 minutes  the
     process  will  sleep  until the lock is available. The sleep
     algorithm is to  sleep  for  5  seconds  times  the  attempt
     number.  That is, the first sleep will be for 5 seconds, the
     next sleep will be for 10 seconds, etc. until the number  of
     attempts reaches  _r_e_t_r_y_c_n_t.

     When the lockfile is no longer needed, it should be  removed
     by calling mailunlock().

     The _u_s_e_r argument is the login name of the  user  for  whose
     mailbox  the  lockfile  will  be created. maillock() assumes
     that user's mailfiles  are  in  the  ``standard''  place  as
     defined in  <maillock.h>.

RETURN VALUES
     Upon successful completion, .maillock() returns 0. Otherwise
     it returns -1.

FILES
     /var/mail/*


SunOS 5.8           Last change: 29 Mar 1999                    1

User Mailbox Library Functions                    maillock(3MAIL)

           user mailbox files

     /var/mail/*.lock
           user mailbox lockfiles

ATTRIBUTES
     See attributes(5) for descriptions of the  following  attri-
     butes:

     __________________________________________________________
    |       ATTRIBUTE TYPE        |       ATTRIBUTE VALUE      |
    |_____________________________|____________________________|
    | MT-Level                    | Unsafe                     |
    |_____________________________|___________________________|


SEE ALSO
     libmail(3LIB),attributes(5)

NOTES
     The mailunlock() function  will  only  remove  the  lockfile
     created  from  the most previous call to maillock(). Calling
     maillock() for different users without intervening calls  to
     mailunlock() will cause the initially created lockfile(s) to
     remain, potentially  blocking  subsequent  message  delivery
     until the current process finally terminates.
-- snip --

Does *BSD have the |maillock| function ?

Comment 3

[Archie Cobbs]

BSD doesn't have maillock(). More generally, not every system will.
So some sort of configure-time logic is in order. Obviously if maillock()
exists that would be the thing to use on any particular system.

Comment 4

[Philip K. Warren]

This patch removes all of the existing locking functionality which is needed on
other platforms. I believe the reason this was written in this manner was to
behave properly on NFS mounted mail spools.

Does the current implementation not properly lock the mail file on FreeBSD?

Comment 5

[Archie Cobbs]

Sorry for the misunderstanding. The patch is merely a workaround for
this problem on my local machine and not intended as a candidate fix.
It's just here to show how to do locking on *BSD.

> Does the current implementation not properly lock the mail file on FreeBSD?

That is correct, on FreeBSD other programs simply ignore /var/mail/foobar.lock.
Instead, flock(2) style locking is the accepted way to lock a mail file.

Comment 6

[Roland Mainz]

pkw:
Is it possible to support the |maillock|-API on platforms where it is supported
?

Comment 7

[Philip K. Warren]

I do not currently have the time to implement the patches for 'maillock' 
support (including linking against the 'mail' library and testing for the 
maillock header files), but I will review contributed patches.

Comment 8

[Philip K. Warren]

One issue with the maillock API (at least on Solaris), is that it does not work 
with mail files outside of the normal mail spool directory.

Comment 9

[Philip K. Warren]

I have done a little more research on this, and this is what I can tell from the
various platforms I have access to:

AIX:
- /var/spool/mail - permission 0775, bin:mail
- /usr/bin/mail appears to use lockf to lock the file, other mail readers use a
combination of fcntl and dotlocking (with a setgid utility) to lock the file.

Fedora:
- /var/spool/mail - permission 0775, root:mail
- Common mail readers like mutt are configured to only use fcntl locking of the
mail spool file. /bin/mail appears to use flock to lock the file.

Debian:
- /var/mail - permission 2775, root:mail
- Mail readers use a combination of fcntl locking + dotlocking (with a setgid
utility) to lock the mail spool file.

FreeBSD:
- /var/mail - permission 0775, root:mail
- mail.local uses flock locking exclusively, other programs (like mutt) use a
combination of flock and dotlocking (with a setgid utility).

Solaris 9:
- /var/mail - permission 1777, root:mail
- /usr/bin/mail appears to use dotlocking only while other programs like mutt
default to using dotlocking and fcntl locking.

There doesn't seem to be a correct answer to this problem for all of the
platforms on which Mozilla runs. Some possible ideas:

- Default to using multiple locking methods instead of just dotlocking. For
Linux/Solaris/AIX this would be fcntl + dotlocking, for platforms like FreeBSD
this would be flock + dotlocking.
- It would be nice to allow users who wish to not change permissions on their
mail spool directory an opportunity to disable the internal dotlocking or use an
external setgid mail program (like procmail's 'lockfile' or mutt's
'mutt_dotlock') to create the dotlock.

Comment 10

[Daniel Küstner]

Someone at Netscape (jwz) faced this problem before and made the same kind of
research as you did. The results may be outdated as they are made for Netscape
2, but just for reference: 

http://wp.netscape.com/eng/mozilla/2.0/relnotes/demo/movemail.html

Comment 11

[Serge Gautherie (:sgautherie)]

Filter on "Nobody_NScomTLD_20080620"

Comment 12

[Joshua Cranmer [:jcranmer]]

bug 384774 is likely to get more outreach