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 file. 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 damage, but the security gain is very very useful (procmail code is a bit spaghetti). 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 re-instated.
Hmm - is the issue that postfix expects the mailboxes writable by group mail? Or that it relies on a privileged procmail?
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.