<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body>
<div dir="auto">If it's feasible, turn on command execution in postfix, make sure it's using a private aliases file, and do a "|/whatever" in its global aliases - if the original recipient does NOT have a matching userid, I believe you can have that command
run as root. Running out the door, can't check, but that just occurred to me.</div>
<div dir="auto">-Adam</div>
<div><br>
</div>
<div id="ms-outlook-mobile-signature" dir="auto">Get <a href="https://aka.ms/AAb9ysg">
Outlook for Android</a></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Roundtable <roundtable-bounces@muug.ca> on behalf of Adam Thompson <athompso@athompso.net><br>
<b>Sent:</b> Monday, April 17, 2023 7:58:29 AM<br>
<b>To:</b> Continuation of Round Table discussion <roundtable@muug.ca><br>
<b>Subject:</b> Re: [RndTbl] "washing" a fork/exec to force all groups</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">Why: "security". I don't recall the details, but I think I remember this change - quite a long time ago, and it never affected me.<br>
<br>
The more general solution is broadly accepted to be: stop using procmail. It's ancient, unmaintained code that doesn't meet modern <anything> standards. Ask about procmail problems on any of the MTA mailing lists and you will be soundly and roundly flamed
for still using it.<br>
<br>
If you use Dovecot, you already have a full SIEVE implementation. Of course procmail can do dangerous things that SIEVE refuses to do, but for most sane needs, it's IMHO far superior to .procmailrc syntax. Much like switching from sendmail syntax to postfix
syntax. You might consider that a bug, not a feature, YMMV.<br>
<br>
Penultimately, I think you want procmail to be setuid root, and invoke it with the "-d" flag. It doesn't get installed setuid anymore because (see above) it's ancient, unmaintained, and believed to not be safe to invoke as root.<br>
<br>
As to sudo, the usual solution is to put your users in a group and allow the group instead of the user. You could "rootwash" procmail itself by using a wrapper script that sudo's procmail instead of having procmail sudo php. You could theoretically have postfix
invoke "sudo postfix" but that might be more trouble than it's worth.<br>
<br>
If you don't have root on the box? Just use .forward files. First character on the first line is "|" = exactly what you're doing with procmail. Wait, you still have the secondary group problem, so maybe SSH to localhost to get the grous back? I'm not sure
how to regain secondary groups without a root process adding them, sorry.<br>
-Adam<br>
<br>
<br>
-----Original Message-----<br>
From: Roundtable <roundtable-bounces@muug.ca> On Behalf Of Trevor Cordes<br>
Sent: Monday, April 17, 2023 3:52 AM<br>
To: MUUG RndTbl <roundtable@muug.ca><br>
Subject: [RndTbl] "washing" a fork/exec to force all groups<br>
<br>
Just ran into this:<br>
<br>
<a href="https://stackoverflow.com/questions/8568596/procmail-disregards-etc-group#">https://stackoverflow.com/questions/8568596/procmail-disregards-etc-group#</a><br>
<br>
Postfix is doing something before/while it calls procmail for local<br>
delivery which strips all but the primary group of the recipient. This<br>
means any complicated pipe I have setup in procmail which relies on<br>
secondary groups fails with read perm errors.<br>
<br>
Sendmail doesn't do this stupidity (yay)! But I needed to (argh finally)<br>
use postfix on a box that needed 2 MTAs installed (and sendmail couldn't,<br>
in the end, do it properly).<br>
<br>
I consider the current stackoverflow answer to be a non-answer because<br>
Fedora/RHEL doesn't install procmail setgid/setuid anymore, and I don't<br>
want to fudge u+s g+s on every dnf update!<br>
<br>
I've solved the problem by "washing" the procmail piped-to command through<br>
sudo. I had to add to sudoers:<br>
fooman ALL=(fooman) NOPASSWD: /bin/php<br>
<br>
and change my procmail recipe pipe to:<br>
| /bin/sudo -u fooman /bin/php /needs/secondary/groups/to/read.php<br>
<br>
Ok great, it all works with postfix now just like it did with sendmail.<br>
<br>
The tricky question for you uber *nix geeks is: Can I achieve the same<br>
thing without the sudoers entry? In other words, is there a way to<br>
achieve this without root access, if someone didn't have root on the box,<br>
say.<br>
<br>
Too bad sudo isn't smart enough to say "hey, user fooman can run anything<br>
as user fooman" without a specific entry. Maybe an option for postfix?<br>
Maybe some magic sudo or su can do?<br>
<br>
Is an option to procmail possible or is this a problem that can *only* be<br>
solved by washing the call, somewhere along the line, through a setuid<br>
program (because once stripped by postfix they are gone forever)?<br>
<br>
I wonder why sendmail doesn't chop off the groups but postfix does.<br>
_______________________________________________<br>
Roundtable mailing list<br>
Roundtable@muug.ca<br>
<a href="https://muug.ca/mailman/listinfo/roundtable">https://muug.ca/mailman/listinfo/roundtable</a><br>
<br>
_______________________________________________<br>
Roundtable mailing list<br>
Roundtable@muug.ca<br>
<a href="https://muug.ca/mailman/listinfo/roundtable">https://muug.ca/mailman/listinfo/roundtable</a><br>
</div>
</span></font></div>
</body>
</html>