I just did a quick test with RH7.1beta1 plus the following tweak:
chmod -s /usr/bin/procmail
With this tweak in place, mail delivery still works fine - both remote and
local. Furthermore, procmail is still invoked by sendmail - I put in a
.procmailrc file and it triggered fine.
Also, I tried the test without a /var/spool/mail/chris (procmail does not
have permission to create this file). But sendmail itself created the file
before invoking procmail, so even in this case everything worked fine.
I only saw one difference - the permissions on the created mail spool
With suid procmail:
-rw-rw---- chris mail
Without suid procmail:
-rw------- chris mail
And to be honest I prefer the 2nd permissions - a group mail breakage
doesn't get access to private mail.
Comments from a sendmail/procmail/mail in general guru please.
As far as I can tell, losing the suid bits has no serious functional
but the security gain is very very useful (procmail code is a bit
This change should probably be done early in the beta cycle to catch
any unexpected side effects...
Setuid/setgid bits removed in procmail-3.14-6.
Verified with beta3. Thanks!
This is very nice, but... now Postfix can't deliver local mail anymore (tested
with Postfix as delivered in the RH 7.1 Powertools).
Sounds like a Postfix bug or configuration error.
I'd be disappointed to see the suid-bits on procmail
Hmm - is the issue that postfix expects the mailboxes
writable by group mail? Or that it relies on a privileged
From the Postfix main.cf configuration file:
# The mailbox_command parameter specifies the optional external
# command to use instead of mailbox delivery. The command is run as
# the recipient with proper HOME, SHELL and LOGNAME environment settings.
# Exception: delivery for root is done as $default_user.
So, setgid mail for procmail (without setuid root) would work (and I verified
this), but not for mail to root. Postfix is designed to be very secure, but
this is done by handing over permission problems to other programs :-(.
Mail should _never_ be delivered to root itself. Always alias root to a normal
user in the aliases map!
I agree, but I'm not sure whether I want this to be *enforced* by the software.
This is UNIX, with all freedoms of choice... Nevertheless, you then still need
the setgid mail bit of procmail.
It should be secure by default. People who want to shoot themselves into their
feet can do so... given they find man chmod :-)
The permissions on procmail are not going to change (I don't trust it).
If this causes problems for postfix, open a bug against it (and please add me to
the CC line).
Did someone open a bug against postfix? I'm playing with this a bit, and I can't
get the 6.2 procmail update to work with postfix *even if I reenable the suid
bits*! The 3.14 package works fine.