On 2023-04-17 Adam Thompson wrote:
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.
Hmm, that would be an interesting discussion in and of itself. I'm at a loss as to how allowing the user their normal groups could present a security threat. Unless of course this is yet another case of the modern practice of infantilizing the user ("they are too stupid to not shoot themselves in the foot"); though those scenarios usually result in a conf option that defaults to "safe", not the complete removal of a useful feature.
The more general solution is broadly accepted to be: stop using procmail. It's ancient, unmaintained code that doesn't meet modern
Haha, we always have this discussion. I use procmail for the same reason I use sendmail: it's in the repos, the install isn't telling me it's deprecated, I know it intimately, have many installs/configs in place using it, and it works great. Do you have any idea how much time I've saved in my life by not jumping into the "latest thing" daemon just because?
(And now I can safely say after having to replicate a sendmail setup in postfix that postfix is just as insane, messy and illogical to configure as sendmail!)
If I must learn something new, I'll wait until they come out with Postsendfixmail-ng and just skip straight to that. :-)
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.
I'll look into SIEVE. However, this particular use case is to run a bot-ish thing on the email address. If SIEVE is some sort of client-y thing then I'm just adding an extra layer (dovecot) for no reason.
You could "rootwash" procmail itself by using a wrapper script that sudo's procmail instead of having procmail sudo php.
Ya, I thought of that, but still needs root to edit sudoers.
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. -Adam
I do have root, but I wanted a "better" answer that doesn't involve root to update the stackoverflow with a "real" answer.
Your ssh idea would probably do the trick!! But man is that sure cheeseball. Ugh, pains me to even think about the silliness of it. But it would work I'm pretty sure!!
Man, that would be ridiculous if the only way to get these groups back is to run through ssh!
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. -Adam
Hmm, I'll check that out too. The big assumption there is that postfix hasn't dropped root in that sub-daemon and/or at that point in the master daemon. Not that I want my program to run as root! But I could have it (or a wrapper) drop root before execution.
Of course, if postfix allows this, it boggles the mind why it wouldn't give an option to keep normal groups in the local delivery agent.
On 2023-04-17 Gilbert Detillieux wrote:
If you do resort to a wrapper of some sort, and don't want it to have full setuid-root privileges, you may be able to get by with just setting CAP_SETGID capability on the binary. That's all that setgroups*(2) would need, if the man page is to be trusted. (However, setting just that on the procmail binary may not be sufficient, if it's expecting more privileges than that. But it would be worth a try.)
Hmm, I'll check that out, too. However, that change would also need root access to effect, and would (probably) get hosed on every dnf update of that rpm. In the end while safer than setuid, it has similar problems.
On 2023-04-17 Gilbert Detillieux wrote:
You may also just want to rethink the root problem (no pun intended). Do you really need secondary groups, or could a simple change to some file ownership and/or permissions accomplish the same thing? Or changing the primary group on the affected user(s)? Of course, those solutions could turn out to be worse than the problem, so YMMV.
That's a decent idea. However, I'm always a bit freaked out making a user's primary group something other than their eponymous group. Not sure if that's justified or not, but it gives me the heebie-jeebies like I'm breaking some cardinal rule and K&R will come to my house and beat me up.
In my case the program lies in a super complex tree into a git repository of php with strange group structure designed to eliminate the need for world read on the php files themselves. Changing that structure would be impossible in this case. But changing the primary group would work, with probably the only downside being any logs the program makes would be group-permed as the "new" primary group.
The more I think about this problem, the more angry I am with postfix and any other program that arbitrarily drops secondary groups! I think it took me 2 hours to debug this problem (learned way more about procmail debugging than I ever wanted to know). All because someone decided that they'll do some wacky group nonsense that I'm not sure I've ever seen any daemon do(?). It's not expected by the user, poorly documented, and seemingly pointless (see my comment at the top of this email).
I kept getting a whiff of "it looks like it's dropping groups" but kept saying "nah, it can't be insane, must be another problem" and going down the wrong rabbit hole. Until I reached the Sherlock Holmes moment.
This "feature" is documented, but only after a convoluted search on the 143 man/doc files in the rpm. And no where is there an explanation:
mailbox_command (default: empty) Optional external command that the local(8) delivery agent should use for mailbox delivery. The command is run with the user ID and the primary group ID privileges of the recipient. ... Mailbox delivery can be delegated to an external command specified with the mailbox_command_maps and mailbox_command configuration parameters. The command executes with the privileges of the recipient user (exceptions: secondary groups are not enabled...
For my future reference and ease: zgrep -iP 'primary group|secondary group|/etc/group' `rpm -ql postfix | grep -iP "man|doc"` | grep --color -iP 'primary group|secondary group|/etc/group'
I'll try out both your ideas and then update the stackoverflow. Don't worry, I'll take the heat for being the luddite procmail neanderthal!