bugThe nmh Mail Handling System - Bugs: bug #25043, slocal can't lock user's default...

 
 

bug #25043: slocal can't lock user's default mailspool if it is dotlock+only-group-mail-writeable

Submitter:  David Fellows <davef>
Submitted:  Tue 09 Dec 2008 12:55:48 AM UTC
   
 
Category:  Bug Severity:  3 - Normal
Priority:  * 5 - Normal Status:  Wont Fix
Assigned to:  None Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 08 Sep 2012 02:01:09 PM UTC, comment #8: 

As of nmh 1.5, configure selects fcntl locking by default on Linux.  So this should no longer be a problem.

David Levine <levine>
Group administrator
Thu 01 Jan 2009 10:46:48 PM UTC, comment #7: 

Yes its not.

fellows@kanga ~ $ ls -ld /var/mail
lrwxrwxrwx 1 root root 15 Oct 26  2006 /var/mail -> /var/spool/mail
fellows@kanga ~ $ ls -ld /var/spool/mail
drwxrwxr-x 2 root mail 4096 Jan  1 18:32 /var/spool/mail


This is a standard gentoo arrangement.

David Fellows <davef>
Thu 01 Jan 2009 09:29:56 PM UTC, comment #6: 

Ah, I think I got confused by a remark in your gentoo bug report about flock().

The dot-locking-without-liblockfile case is actually a very common one and we don't want to get rid of it.

Is your problem possibly that on your system /var/mail is not writable by normal users? (This is a common setup, Debian for instance uses it). liblockfile copes with this (by spawning a setgid mail helper) as described in the PERMISSIONS section of the lockfile_create(3) manpage. nmh is supposed to notice the dotlock-with-unwritable-maildir case -- if it does it makes inc setgid mail. However it doesn't do anything about slocal, so if slocal tries to deliver mail to your mailspool it falls over.

So yes, you're right that there is a bug here:

  • slocal can't deliver to only-writable-by-group-mail mailspools if it is doing dotlocking


The obvious fix is to make the install process mark slocal as setgid mail in the same way it does inc. But before we do that I'd need to update the code so it's not a security hole to do that (like inc it would need to be careful about dropping and regaining permissions and so on).

Peter Maydell <pm215>
Group administrator
Thu 01 Jan 2009 08:18:00 PM UTC, comment #5: 

I don't think the bug is invalid. It might not be worth fixing. Mostly I filed it to document the problem.

From a quick scan through sbr/lock_file.c it appears to me that nmh will use one (or more) methods for locking

  1. flock
  2. lockf
  3. dot file locking
  4. dot file locking using liblockfile


Methods one and two are specified with configure parameters. Method 4 is used if  configure test detects the presence of liblockfile. Method 3 is used otherwise. 

Method 3 is what this bug is against.  Is far as I tested Methods 1,2 and 4 all work. 

I agree that the selection of method has to be compatible with the methods used by other programs (if any) accessing the mail files.  In my particular setup I think only nmh programs are accessing my mail files and directories and all my mails stuff is on a local disk so my choice of method is arbitrary.

Maybe the best fix is to eliminate Method 3 by having configure stop with a suitable error message if it does not detect liblockfile and neither lockf or flock are explicitly specified.

David Fellows <davef>
Mon 29 Dec 2008 10:30:07 PM UTC, comment #4: 

The matter of configuring which locking strategy to use for the mail spool is an area where nmh seems to run into problems. My personal opinion is that:

  • how you lock the mail spool is a system configuration issue which should be clearly defined in the distribution's documentation somewhere (for example Debian's Policy Manual says "fcntl plus dotlocking").
  • there's no way to automatically probe for what the distribution uses
  • therefore when you build nmh you must make the right choice, and if you make the wrong one then locking will probably not work (either noisily, as here, or silently by corrupting your mail in a race condition later)


It's arguably a bug that configure has a default for locking style at all -- it ought to be more up front about making you specify.

So my take on this is that this was a gentoo packaging bug, which I has been resolved correctly on the gentoo side, assuming that gentoo's liblockfile matches its mail spool locking policy :-)

So my inclination is to resolve this as Invalid, but I'll leave it be for a little in case you want to comment.

Peter Maydell <pm215>
Group administrator
Wed 10 Dec 2008 01:32:38 AM UTC, comment #3: 

For the record,
I added --with-locking=lockf as a parameter to configure
removed the liblockfile package and rebuilt nmh.

comp, send, and slocal all worked fine.

David Fellows <davef>
Tue 09 Dec 2008 02:25:56 AM UTC, comment #2: 

I filed a bug on this to gentoo.
https://bugs.gentoo.org/show_bug.cgi?id=250340

I suggested making liblockfile an explicit dependency for nmh.

David Fellows <davef>
Tue 09 Dec 2008 01:25:07 AM UTC, comment #1: 

Oops. A syntax error dropped my system description.
 
My system is briefly described by:

# uname -a
Linux kanga 2.6.20-gentoo-r8 #1 SMP PREEMPT Sun Aug 5 23:02:09 ADT 2007 x86_64 AMD Opteron(tm) Processor 246 AuthenticAMD GNU/Linux
# gcc --version
gcc (GCC) 4.1.2 (Gentoo 4.1.2 p1.0.1)
glibc-2.6.1


David Fellows <davef>
Tue 09 Dec 2008 12:55:48 AM UTC, original submission:  

I built nmh-1.3 as distributed by gentoo Linux. I did not have the dotlockfile package which provides lockfile.h and friends installed.  I very shorlty found that no mail was being to delivered to me.

I then used the following command as a test case:

   slocal -user fellows -verbose -debug -file /home/fellows/Mail/inbox/182

Message 182 is a short ascii text message produeced using nmh-1.1 comp; send; fetchmail; slocal; inc;

When running the above command as user fellows after the .forward parsing messages there is a delay of 60 seconds followed by these final messages:

delivering to file "/var/spool/mail/fellows" (mbox style), unable to open:No such file or directory
(delivering to standard mail spool)
delivering to file "/var/mail/fellows" (mbox style), unable to open:No such
file or directory

But both files exist with permissions rw-------  and are owned by fellows.
 
I then installed the liblockfile package and re-installed nmh-1.3. this time the test case succeeded with the final message reading:

  delivering to file "/var/spool/mail/fellows" (mbox style), success.

A following inc put the message in my inbox as expected.

My current nmh-1.1 was built with the configure parameter --with-locking=lockf.
If I get a chance in the next day or so I will try building 1.3 with this and without the libdotlockfile package available.


My system is briefly described by:

# uname -a
Linux kanga 2.6.20-gentoo-r8 #1 SMP PREEMPT Sun Aug 5 23:02:09 ADT 2007 x86_64 AMD Opteron(tm) Processor 246 AuthenticAMD GNU/Linux
# gcc --version
gcc (GCC) 4.1.2 (Gentoo 4.1.2 p1.0.1)
glibc-2.6.1
--vertbatim-

David Fellows <davef>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by levine (Posted a comment)
  • -email is unavailable- added by pm215 (Posted a comment)
  • -email is unavailable- added by davef (Submitted the item)
  •  

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2012-09-08 levine StatusNone Wont Fix
        Open/ClosedOpen Closed
    2009-01-04 pm215 Summarynmh-1.3 slocal fails to deliver mail when built without dotlockfile present. slocal can't lock user's default mailspool if it is dotlock+only-group-mail-writeable
    2009-01-01 pm215 CategoryNone Bug

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code