Bug 43365 - procmail fails to create mail spool file for new users
Summary: procmail fails to create mail spool file for new users
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Powertools
Classification: Retired
Component: postfix
Version: 7.1
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Bernhard Rosenkraenzer
QA Contact: David Lawrence
URL:
Whiteboard:
: 60073 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-06-04 03:11 UTC by Chuck Mead
Modified: 2007-04-18 16:33 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2003-05-16 16:49:08 UTC
Embargoed:


Attachments (Terms of Use)

Description Chuck Mead 2001-06-04 03:11:42 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i686; en-US; rv:0.9+)
Gecko/20010531

Description of problem:
On several boxes I have in production, when I create a new user I have to
manually create their /var/spool/mail/$user file because procmail cannot
create a lock file in /var/spool/mail/

How reproducible:
Always

Steps to Reproduce:
1. create a new user rickf
2. send new user rickf an email
3. procmail fails to deliver the mail


	

Actual Results:  Jun  3 22:56:40 server postfix/local[29238]: 8B5D315CCD:
to=<rickf.com>, relay=local, delay=0, status=bounced
(can't create user output file. Command output: procmail: Couldn't create
"/var/spool/mail/rickf" procmail: Lock failure on
"/var/spool/mail/rickf.lock" procmail: Error while writing to
"/var/spool/mail/rickf" )

Expected Results:  procmail should have been able to create the users spool
file and it should be able to lock that file when needed. otherwise
procmail is useless as an MDA/LDA.

Additional info:

I am able to overcome the problem by manually creating the users spool file
with permissions 0660 and ownership rickf.mail.

Comment 1 Chuck Mead 2001-06-04 03:31:50 UTC
I tried updating to the version of procmail in the current rawhide
(procmail-3.15.1-1.i386.rpm) and the problem persists.

Comment 2 Chuck Mead 2001-06-04 03:43:20 UTC
I downgraded my version of procmail to the version that comes with RH7.0 and it
now works as expected. The only thing in the changelog between the 7.0 and the
7.1 release is this:

* Sat Jan  6 2001 Jeff Johnson <jbj>
- lose setuid/setgid (root,mail) bits (#23257).

Comment 3 Trond Eivind Glomsrxd 2001-06-04 03:57:55 UTC
It works with sendmail... postfix would like procmail to be setgid, and it isn't
trustworthy enough to get that.

*** This bug has been marked as a duplicate of 41693 ***

Comment 4 Chuck Mead 2001-06-04 19:04:49 UTC
In all likelihood this bug should be re-assigned to bero as Tim says that
postfix now belongs to him. Postfix' author has been apprised and has
communicated a bit with Trond. He wants to support postfix "out of the box".

Comment 5 Trond Eivind Glomsrxd 2001-06-05 14:00:49 UTC
Reassigning to postfix owner... he's currently on holiday, so a response from
him might take some time.

Comment 6 Bernhard Rosenkraenzer 2001-08-31 18:03:25 UTC
If you have any good suggestions at fixing this, let me know - I don't see a 
good way to do it.

The problem is that postfix isn't setuid/setgid (which is good), so if the 
delivery agent (procmail) isn't running setuid/setgid, the user's initial 
mailspool can't be created.

I can offer the following resolutions:
- Make postfix setuid/setgid. Bad idea, it would remove one of the best points
  of postfix.
- Make procmail setuid/setgid. Bad idea, for the reasons the setgid bit was
  removed in the first place.
- Mark this bug "RESOLVED: CURRENTRELEASE" with the note "package removed"
- Mark this bug "RESOLVED: NOTABUG" with the note that the admin should have
  created the initial mailspool and make it writable by the user

If you have any better ideas, let me know - I don't see any.

Comment 7 Chuck Mead 2001-08-31 18:12:26 UTC
Perhaps a simple way around it (woldn't hurt anything even if the intended shell
was /bin/false) is to add a touch string to the adduser script? Just an idea...
what do you think?

Comment 8 Bernhard Rosenkraenzer 2001-08-31 18:25:18 UTC
I actually did that initially, but it was reverted because it creates too much 
unnecessary junk on authentication servers with lots of users that aren't mail 
servers - and it doesn't fix the problem for mail servers that get user 
information over NIS, LDAP or something similar, so that's not an option 
either.


Comment 9 Matthew Miller 2001-09-11 13:21:39 UTC
There is a problem beyond the creation of the initial mailspool. The non-setuid 
procmail (with postfix) also can't do much of what one might use procmail 
*for* -- delivering directly into various mailboxes in users' home directories.

If I understand what's going on, under sendmail, the MTA is already setuid 
root, and so there's not really any particular gain in removing the bit from 
procmail...

I see above that postfix's author was contacted about this; does he have any 
suggestions?


Comment 10 Daniel Resare 2002-01-06 22:40:37 UTC
Delivery into a user's own mailboxes in $HOME wouldn't be a problem, since the
delivery will be done as the user recieving the email.

The correct solution IMHO would be for procmail to use a specialized sgid helper
app that has the responsibility of delivering mail (and creating an initial
spool file) to /var/spool/mail, much like mutt does it.

Comment 11 Bernhard Rosenkraenzer 2002-02-21 15:59:42 UTC
*** Bug 60073 has been marked as a duplicate of this bug. ***

Comment 12 David Lawrence 2003-05-16 16:49:08 UTC
Closing as WONTFIX due to end of life of the Power Tools product line. Please
open a new bug report under the Red Hat Linux product if the component is still
included in the base Red Hat distribution.


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