Bug 23257 - Lose the suid/sgid bits please!
Lose the suid/sgid bits please!
Product: Red Hat Linux
Classification: Retired
Component: procmail (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Trond Eivind Glomsrxd
David Lawrence
: Security
Depends On:
  Show dependency treegraph
Reported: 2001-01-03 18:36 EST by Chris Evans
Modified: 2007-04-18 12:30 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-05-22 09:18:05 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Chris Evans 2001-01-03 18:36:16 EST
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...
Comment 1 Jeff Johnson 2001-01-06 17:06:44 EST
Setuid/setgid bits removed in procmail-3.14-6.
Comment 2 Chris Evans 2001-02-05 17:59:03 EST
Verified with beta3. Thanks!
Comment 3 Jos Vos 2001-05-22 07:42:20 EDT
This is very nice, but... now Postfix can't deliver local mail anymore (tested
with Postfix as delivered in the RH 7.1 Powertools).
Comment 4 Chris Evans 2001-05-22 07:56:40 EDT
Sounds like a Postfix bug or configuration error.
I'd be disappointed to see the suid-bits on procmail
Comment 5 Chris Evans 2001-05-22 07:58:16 EDT
Hmm - is the issue that postfix expects the mailboxes
writable by group mail? Or that it relies on a privileged
Comment 6 Jos Vos 2001-05-22 08:06:01 EDT
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 :-(.
Comment 7 Daniel Roesen 2001-05-22 08:13:09 EDT
Mail should _never_ be delivered to root itself. Always alias root to a normal
user in the aliases map!
Comment 8 Jos Vos 2001-05-22 09:14:00 EDT
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.
Comment 9 Daniel Roesen 2001-05-22 09:18:00 EDT
It should be secure by default. People who want to shoot themselves into their
feet can do so... given they find man chmod :-)
Comment 10 Trond Eivind Glomsrxd 2001-05-22 10:00:47 EDT
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).
Comment 11 Matthew Miller 2001-08-26 12:09:17 EDT
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.

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