Red Hat Bugzilla – Bug 43365
procmail fails to create mail spool file for new users
Last modified: 2007-04-18 12:33:33 EDT
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@server.moongroup.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.
I tried updating to the version of procmail in the current rawhide (procmail-3.15.1-1.i386.rpm) and the problem persists.
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@redhat.com> - lose setuid/setgid (root,mail) bits (#23257).
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 ***
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".
Reassigning to postfix owner... he's currently on holiday, so a response from him might take some time.
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.
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?
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.
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?
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.
*** Bug 60073 has been marked as a duplicate of this bug. ***
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.