procmail disregards /etc/group?

Question

sample procmailrc:

SHELL=/bin/bash
LOGFILE=$HOME/procmail.log
VERBOSE=yes

:0
* ^Subject: envdump please$
{
        LOG="`id`"
            :0
            /dev/null
}

/etc/group file contains (note the other usernames are vain attempts to make this work):

someuser:x:504:
s3:x:505:someuser,someotheruser,postfix,postdrop,mail,root

If I run as "someuser" the command id:

[someuser@lixyz-pqr ~]$ id
uid=504(someuser) gid=504(someuser) groups=504(someuser),505(s3)

However when I run procmail by sending an email with the subject "envdump please", the 505/s3 group disappears (this is in procmail.log):

procmail: [17618] Mon Dec 19 17:39:50 2011
procmail: Match on "^Subject: envdump please$"
procmail: Executing "id"
procmail: Assigning "LOG=uid=504(someuser) gid=504(someuser) groups=504(someuser)"
uid=504(someuser) gid=504(someuser) groups=504(someuser)procmail: Assigning "LASTFOLDER=/dev/null"

this server is running Fedora 14 with Postfix 2.7.5

Fun to see the old Procmail Debugging Tips page still gets usage (-: http://partmaps.org/era/mail/procmail-debug.html — tripleee, Dec 21 '11 at 10:43

score 1 · Accepted Answer · answered Dec 20 '11 at 20:34

1

Procmail wasn't installed setuid.

for background, it should look like:

[root@li321-238 postfix]# ls -l /usr/bin/procmail 
-rwsr-sr-x. 1 root mail 92816 Jul 28  2009 /usr/bin/procmail

which you can set up via:

chmod ug+s /usr/bin/procmail

answered Dec 20 '11 at 20:34

zzzeek

72,307
23
193
185

score 0 · Answer 2 · answered Apr 20 '23 at 04:32

I assume you are using postfix with procmail. Postfix, for reasons I cannot find, strips the supplementary groups from the recipient user when it runs procmail as that user. That is why your procmail LOG example only shows the primary id, even though your /etc/groups lists more group membership. (Sendmail does not do this; it's a postfix thing.)

My solution is to force the recipient user to get its normal group permissions back by washing the command through sudo. No user or primary group change takes place, all we are doing is getting the supplementary groups to revert to what /etc/group says they should be. This only works if you have root access or some other access to edit sudoers.

Edit your /etc/sudoers (or make a new .d file) and add:

someuser ALL=(someuser) NOPASSWD: /bin/id

where /bin/id is the program you want to run in your procmail recipe with the correct supplementary groups.

Then change your procmail recipe to wash your command through sudo:

| /bin/sudo -u someuser /bin/id

If you do not have root access, you could effect a similar wash through ssh with public keys (not passwords). Or you could create a daemon that listens on a named pipe (though keeping the daemon running may require root: i.e. with a systemd service file). Another option, if feasible, is to set your primary group in /etc/passwd to the one you need for this procmail call. But of course that limits you to fixing things in this manner for just this one call.

Further details: postfix is calling setgroups() before calling procmail, with just the primary group as the supplemental group list. It doesn't have to do this, but the programmers decided it should. I cannot find documentation as to why it does this. I cannot really understand how this would help security in any way.

I investigated using newgrp or sg to reset the supplemental groups, but no matter what I could not get it to restore them, even though the source code makes it appear it should. Using strace it would appear the kernel capabilities system prohibits regaining those groups once they are dropped.

procmail disregards /etc/group?

2 Answers2