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.)

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.

Gilbert

On 2023-04-17 7:58 a.m., 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.

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.

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.

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.

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.

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

-----Original Message----- From: Roundtable roundtable-bounces@muug.ca On Behalf Of Trevor Cordes Sent: Monday, April 17, 2023 3:52 AM To: MUUG RndTbl roundtable@muug.ca Subject: [RndTbl] "washing" a fork/exec to force all groups

Just ran into this:

https://stackoverflow.com/questions/8568596/procmail-disregards-etc-group#

Postfix is doing something before/while it calls procmail for local delivery which strips all but the primary group of the recipient. This means any complicated pipe I have setup in procmail which relies on secondary groups fails with read perm errors.

Sendmail doesn't do this stupidity (yay)! But I needed to (argh finally) use postfix on a box that needed 2 MTAs installed (and sendmail couldn't, in the end, do it properly).

I consider the current stackoverflow answer to be a non-answer because Fedora/RHEL doesn't install procmail setgid/setuid anymore, and I don't want to fudge u+s g+s on every dnf update!

I've solved the problem by "washing" the procmail piped-to command through sudo. I had to add to sudoers: fooman ALL=(fooman) NOPASSWD: /bin/php

and change my procmail recipe pipe to: | /bin/sudo -u fooman /bin/php /needs/secondary/groups/to/read.php

Ok great, it all works with postfix now just like it did with sendmail.

The tricky question for you uber *nix geeks is: Can I achieve the same thing without the sudoers entry? In other words, is there a way to achieve this without root access, if someone didn't have root on the box, say.

Too bad sudo isn't smart enough to say "hey, user fooman can run anything as user fooman" without a specific entry. Maybe an option for postfix? Maybe some magic sudo or su can do?

Is an option to procmail possible or is this a problem that can *only* be solved by washing the call, somewhere along the line, through a setuid program (because once stripped by postfix they are gone forever)?

I wonder why sendmail doesn't chop off the groups but postfix does.

Poking around I found newgrp and sg, both of which look promising to "reset" the groups to what the user has in /etc/groups. Especially since newgrp (and sg which is a link to it) is setuid root.

But alas, after much screwing around, they fail with:

setgroups(2, [1410, 5200]) = -1 EPERM (Operation not permitted) (thanks strace)

Ok, so hit the source. The program is all happy up until the setgroups syscall. Which means it understands the user is *allowed* to reset the groups as per the config of /etc/groups.

https://github.com/shadow-maint/shadow/blob/master/src/newgrp.c

But when it actually does it, the kernel says nope. Ok great, but why is this? newgrp is running as root at that point, no? (I can't see it dropping its perms in the src.) As root it should have that CAP that Gilbert mentioned, no?

I'm bummed because newgrp/sg really looked like the holy grail: a standard program already in the distros, already with setuid, and will "do the right thing" for me.

So why doesn't it work?

... I wonder if it works on a pre-capabilities kernel...

On 2023-04-18 Gilbert Detillieux wrote:

Uhm... You may be experiencing a "Heisenbug" here, in that use of strace by a non-root user will nullify any setuid/setgid effect on the binary being traced. So, the EPERM error may have only been due to strace, and not an actual underlying problem/limitation in either setgroups(2) or the newgrp command.

I didn't know that! Are you positive it's still true in the most modern systems (see below)? Thanks for the info, definitely something to keep in mind. Almost as obscure as daemons dropping supplemental groups :-) (Actually, more obscure, so you win!)

I'm having the procmail recipe output the following:

id0: `/bin/id`

id1a: `/bin/sg ewordr /bin/id` id1b: `/bin/sg szpostmaster /bin/id`

id2a: `/bin/newgrp ewordr; /bin/id` id2b: `/bin/newgrp szpostmaster; /bin/id`

id3a: `/bin/strace /bin/sg ewordr /bin/id` id3b: `/bin/strace /bin/sg szpostmaster /bin/id`

The results are:

id0: uid=1410(szpostmaster) gid=1410(szpostmaster) groups=1410(szpostmaster)

id1a: id1b: uid=1410(szpostmaster) gid=1410(szpostmaster) groups=1410(szpostmaster)

id2a: uid=1410(szpostmaster) gid=1410(szpostmaster) groups=1410(szpostmaster) id2b: uid=1410(szpostmaster) gid=1410(szpostmaster) groups=1410(szpostmaster)

id3a: id3b: uid=1410(szpostmaster) gid=1410(szpostmaster) groups=1410(szpostmaster)

(The straces are outputted earlier, but not too useful here as they mirror what I already said.)

szpostmaster is the user and primary group name. "Changing" to it works fine as I guess the kernel cap allows that. ewordr is the supplemental group I'm trying to reinstate. (Strange that id2a doesn't fail like the other a's.) No output means the newgrp/sg blew up and never ran the command.

What I *want* to see as output is: id2a: uid=1410(szpostmaster) gid=1410(szpostmaster) groups=...(szpostmaster,ewordr)

And regardless of whether I try to newgrp or sg to eword or szpostmaster, the source indicates it should restore the supplemental groups to what /etc/group says.

Note too how id3* doesn't differ from id1*, which makes me unsure whether Gilbert's strace note is actually occurring. Either that or they are failing in different ways. The only way I'll figure that out is by compiling newgrp myself and putting in a whackton of printf statements. And I just might do it...

(or "sg", which I wasn't aware of until you pointed it out).

Ya, it was news to me too. Funny, that. Love the command name, though!! Haha. Suck it PowerShell users!! ;-) (JOKING, NO FLAMES PLEASE!)

Very minor note: I just created a new user (via useradd) on Solaris 11.4.53 and the default group is "staff" (uid=10).

On Tue, Apr 18, 2023 at 8:19 AM Adam Thompson athompso@athompso.net wrote:

...

modern practice of infantilizing the user ("they are too stupid to not shoot themselves in the foot");

I mean... that is fact true across the entire IT space. The more people there are in IS/IT and adjacent fields, the more idiots there are who are happily grabbing loaded footguns, aiming them in the traditional manner, duct taping it all together and proudly calling it a "production system" because they don't know any better.

I don't think the average user is too stupid to not shoot themselves in the foot - I think the average IT "professional" is too stupid to not shoot themselves in the foot, based on observed evidence. Present company included, from time to time. It's a variation on the Dunning-Krueger effect: we don't know enough about how deep the skills go in some area that isn't our primary skillset, so we lash together something that looks good but actually makes nearly every possible domain-specific naïve mistake, and we don't know the difference precisely because we're not experts in some field that doesn't obviously scream "this is really really hard". (SMTP email address validation, anyone? Did you know you can legally put spaces in the middle of an address, for example?)

...

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?

I'm far too old and tired to jump on the "latest hotness" bandwagon. But in this case, I've seen multiple MTA maintainers (I think I'm now up to... 5?) explicitly say "don't use procmail, it's unsafe". I'm assuming this many specialists from this many different origins know something I don't. And you'll notice ESR has wholly abandoned it - whether due to feature-completeness, unmaintainability, or general douchebagginess, I can't say.

...

(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!)

In the modern era, I sadly agree. Enter OpenSMTPd, which is rapidly growing enough features and corner cases to make it just as bad. I think this just proves that SMTP should be taken out back and put out of its misery, but I don't expect to see that happen in my lifetime. For better and/or for worse.

...

Postsendfixmail-ng and just skip straight to that. :-)

LOL. Sendmail, Postfix, Exim, OpenSMTPd. Are there any other "major" (unix) MTAs left out there? Should I still have Exim in the list, even?

...

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.

It's designed to do all the filtering things that a normal procmail user would be using it for. Probably not going to help you much. Ofc I still don't understand why you need procmail at all, when aliases(5) supports pipes directly.

Another option could be running your own (e.g.) Perl single-purpose MTA on another port; you already alluded to Postfix being the 2nd MTA on the system, do you need all of it, or it is just to support a single userid-to-pipe? https://metacpan.org/pod/Net::SMTP::Server Warning: take note of the author's handle before using... There are quite a few other SMTP servers in CPAN. I don't see any native PHP servers, surprisingly but thankfully.

...

I do have root, but I wanted a "better" answer that doesn't involve root to update the stackoverflow with a "real" answer.

Sometimes you just need root. Needing root doesn't make the answer less "real".

...

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.

It's not justified. Each user having their own primary group is a Linuxism, and a fairly recent development in UNIX history. On Solaris, when you create a new user, IIRC their default/primary group is still "usr". Because each user having their own group makes the average system much more secure (see "shoot self in foot", above), pretty much everyone has adopted it by now.

...

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.

What about just checking out the git repo, then? Not to mention: how the heck are you getting git to reliably deal with userids and groups? That's very explicitly *not* something git cares about.

-Adam

---

Roundtable mailing list Roundtable@muug.ca https://muug.ca/mailman/listinfo/roundtable

You may see it in your lifetime. The IETF JMAP group is hard at work, nearing final standard. JMAP is the intended replacement for IMAP, and has explicit provision for replacing (or rendering unnecessary) SMTP too. And JMAP fully supports labels (a la Gmail), not just in the e-mail message base, but in contacts, etc., too (a contact can belong to many "labels"/groups), basically, wherever the labels concept makes sense.

I am happily using Fastmail, the world's showcase implementation of JMAP. Gmail (with my own domain names) was my former primary infrastructure, and I am still maintaining it for experiments/education. I just did some fresh DKIM research in Gmail recently.

Hartmut

On Tue 18 Apr 2023 at 08:18:00 -05:00, Adam Thompson athompso@athompso.net wrote:

I think this just proves that SMTP should be taken out back and put out of its misery, but I don't expect to see that happen in my lifetime. For better and/or for worse. -Adam

On 2023-04-18 Adam Thompson wrote:

(SMTP email address validation, anyone? Did you know you can legally put spaces in the middle of an address, for example?)

:-)

$REemail='(?:[\x21\x23-\x27\x2A-\x2B\x2D\x2F-\x39\x3F\x41-\x5A\x5E-\x60\x61-\x7A\x7B-\x7E\x{0080}-\x{FFFF}]+(?:\x2E[\x21\x23-\x27\x2A-\x2B\x2D\x2F-\x39\x3F\x41-\x5A\x5E-\x60\x61-\x7A\x7B-\x7E\x{0080}-\x{FFFF}]+)*|\x22(?:[\x21\x23-\x5B\x5D-\x7E\x{0080}-\x{FFFF}]|\x5C[\x20\x09\x21-\x7E\x{0080}-\x{FFFF}])*\x22)@[\x2Da-zA-Z0-9\x{0080}-\x{FFFF}]+(?:\.[\x2Da-zA-Z0-9\x{0080}-\x{FFFF}]+)+';

Captures most email possibilities, including spaces (in double quotes is the rule). However, currently won't allow plane 3+ UTF8 codes, assuming those are even allowed in emails(?). (Always looking to improve this regex.)

I'm far too old and tired to jump on the "latest hotness" bandwagon. But in this case, I've seen multiple MTA maintainers (I think I'm now up to... 5?) explicitly say "don't use procmail, it's unsafe". I'm assuming this many specialists from this many different origins know something I don't.

Meh, I guess it has to be your "personal" group of specialists before one really pays attention? I'm pretty sure for 80% of the daemons, languages, idioms, etc, I use you could easily find 5 specialists to say it's "unsafe".

And if they think procmail is unsafe, then they should expound on precisely why it is so and post bugzillas about it so someone can make the CVEs! Procmail (at least on my RHEL box) is still included as part of the core supported product meaning we all have an obligation to report sec flaws.

In a similar vein, is vim unsafe? It gets dozens of CVEs every couple of months. emacs has had less than a handful in a decade. Is emacs unsafe? It's still in the core repo of every distro. Just because less people use emacs, and the dev work is much slower, does that mean "don't use emacs"? How about this: maybe emacs and procmail were written properly by far better programmers than vim. Maybe dev has slowed/stopped because they literally "did it all". I have no idea if this is true, but it's a possibility. (I can't think of a single thing I'd need that procmail doesn't already do.) At least CVE count is more of a measurable, objective measurement of "unsafe" than "I know 5 guys".

To be sure, I'm not saying your 5 guys are wrong, or that any one of these things is better than the other, I'm just saying one might want more to go on than anecdotal hearsay. If I listened to that, I'd have written everything in Java for the last 25 years (the horror!).

In the modern era, I sadly agree. Enter OpenSMTPd, which is rapidly growing enough features and corner cases to make it just as bad.

Yes, it is clear to me that is what happened with postfix. They said "oh it's easy to write a SMTP daemon that doesn't have insane m4 nuttiness and replaces sendmail", then they built the guts of it, and then realized there's 800 corner cases and little niggling features they have to support.

The funny thing is, the crazy stuff required for a real MTA these days that was tacked on to sendmail is easier to deal with and almost seems more elegant than postfix. Once you find the magic documentation and the magic letter you have to put in the magic macro, it tends to be easier with less overall config changes than postfix requires.

At the very end of setting up postfix I was definitely left wondering in about 5 obscure config cases "will this really do what I think and not open-relay me?". In sendmail I know for a fact an option is doing what I want. The postfix docs on the obscure options are also very poor, written ambiguously (and maybe by a EASL which really doesn't help when you need precision).

Maybe I sound bitter (moi?!), but I really thought by the hype that postfix was utopia and infinitely superior. Got disenchanted real fast. Wasted a whole day replicating a very complex sendmail config in postfix. On the bright side, it was possible to do, rather than reaching the all-too-common "it can't do XYZ that you absolutely need" 3/4's of the way through the job.

think this just proves that SMTP should be taken out back and put out of its misery, but I don't expect to see that happen in my lifetime.

It's an interesting thought. I think what really should have happened was the sender should have been 100% separated from the receiver in SMTP daemons. Not just a separate process, but a separate config, or even program. And maybe the MTA-MTA comms completely broken out from the MTA-MUA comms. And maybe the private-MTA-public-MTA comms broken out from the all-public MTA comms (by private I mean one controlled by you basically acting like a MUA). I have no idea how this could be architected properly. Maybe that's why it is what it is.

Another option could be running your own (e.g.) Perl single-purpose MTA on another port; you already alluded to Postfix being the 2nd MTA on the system, do you need all of it, or it is just to support a single userid-to-pipe?

Ya, but in this case nope. I need a full-blown MTA to do all the wacky stuff in every direction with every option. Only have so many static IPs we can assign to MTA-like programs, gotta make them count.

I'll tell you something funny, and why I had to use a postfix instance... You can run 2 sendmails on 1 system, and use 2 different IPs. BUT (and I only hit this at the very end of setting up the 2nd sendmail) sendmail cannot set the *outgoing* (source) IP on a per-daemon basis. The 2nd daemon will always send from the first available (i.e. main) system IP. Apparently this might be fixed in a future version. Luckily postfix had an option for this. (Yes, a VM may have helped me here, but I don't virtualize, deal with it. ;-)

I also found a way to simultaneously run sendmail and postfix on the same box, which RHEL really really doesn't want you to do. Haha, that was the fun part. Ya, I could have just run 2 postfixes, but I trust sendmail more for the "more important" IP that must never break.

What about just checking out the git repo, then? Not to mention: how the heck are you getting git to reliably deal with userids and groups? That's very explicitly *not* something git cares about.

Haha, *you* probably know the answer to that. I wrote my own git hooks / system for dealing with perms in a git repo. Definitely not for linux-kernel type dev situations, but perfect for my project with a limited number of devs and a mostly-moves-forward few-branches dev strategy. It really has been perfect for several years now. Yes, that means git is also my deployment tool. git push Live and the new version is live in 3s.

It was MUUG guys on this list that gave me all the ideas a few years back when I didn't know squat about git. P.S. Switching to git was the best move I ever made. Recommended, though there will be some wall-head-bashing, guaranteed.

It's designed to do all the filtering things that a normal procmail user would be using it for. Probably not going to help you much. Ofc I still don't understand why you need procmail at all, when aliases(5) supports pipes directly.

Yes, the more I think about it, the more your alises idea seems the way to go. I simply didn't know about that feature, though I guess I should have as a mm admin for 20 years. Doh. The key will be if postfix really does have that option you mentioned that really will make it not drop the supplementary groups. I will try that next! Love the idea of cutting out the "middleman" programs where possible.

TBH after my sudo fix my interest became more in grokking the fundamental issues regarding this group behavior. Postfix ticked me off; and I love a good unix-y problem to boot. If you ever find the rationale for the "feature", post it to the list! Till then, it's as good a feature as PHP 8's "warning: use of uninitialized array index" feature. Hahaha.

On 2023-04-19 Adam Thompson wrote:

When Wietse says "don't use procmail" many times over the last... 20? yrs, and then Gilles Chehade (OpenSMTPd) also says the same thing, repeatedly, and then I Allman said the same once when I asked in person, I just stop questioning, because I have better things to do with my time than argue with people far better-versed than I in a particular space.

Still meh. Name dropping doesn't excite me. Ya, might perk my ears up a tad more than nobodies, but many will have an agenda. We all know many *BSD people seem to have a severe NIH complex. And the author of Postfix already has a hate-on for anything sendmail-era right out of the gate. If I find 5 prominent UNIXers that still use procmail, does that make me the winner? It's all rather silly. We've had the exact same discussion about sendmail, and ... and ...

Summarizing it, albeit dated: https://lwn.net/Articles/416901/

I love it, it looks like a Lennart or PHP-voting-majority "argument": ====== The merits of the competing filter-writing syntaxes are a bit subjective, but it is easy to see that procmail's recipe syntax is more terse, using non-alphabetic characters and absolute positioning in place of keywords like "if" and "to." ======

Oh noes, it's terse and a computer person might actually have to learn a new "language" like they do all the time when language-du-jour comes out and they have to tweak code. The horror!

The replacement uses "if" so it must be better! Ya ok, maybe to some kid just starting out, but not (again the whole point) someone who has been using it since 1993.

I find this more convincing: "it is feature complete and apparently pretty bugfree"

as it echoes what I said. Why can't the program just be "good" and "done"? I don't rewrite all my 10 and 20 year old code every few years for kicks just because.

<much tongue-in-cheek, and cheekiness; apologies>

One countervailing point: Procmail starting becoming abandonware as of 2001, in 2014 that was codified (see link, above), BUT apparently it's under maintenance again as of 2020 (although the website is dead-ish, sigh). LOL, even the Wikipedia page says: "For approximately ten years, procmail was not maintained, and multiple serious security vulnerabilities[7] were discovered in the intervening time span[3] (since fixed)."

I followed the rabbit hole and it looks like as bugs were found, people talked about it and distros added patches to the src rpms. Sounds par for the course.

But speak of the devil: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006633 scroll to bottom

Someone seems to have taken it over and fixed any recent bugs, including a formail (companion program not used as much) heap overflow. A new version with a new minor number (24) has been released and should worm itself into the distros.

So if the main point is it's "abandonware", then that seems to settle that.

Message #44 in that link is from the original author (van den Berg) himself, and is an interesting read. Especially:

======== What can we learn from this: a. Clearly I had my security focus on procmail back then. But all the critical paths have been audited to pieces before the year 2000. ...

From a statistical standpoint, given the points a) to d) above, I'd say

that procmail/formail have a above average track record and can be trusted. ========

Mic drop?

The only real thing I see in any of the forks' issues pages is handling stuff like UTF8 headers. But in all my time I've yet to see where this is *required*. You can still use procmail regex to match the funky encoded version of whatever header. Ugly, but it works. I have little doubt someone will add support for them into procmail soon, as I'm sure there's pre-existing C libraries to do the conversions, and turning on UTF8 shouldn't be hard (though I do live outside the world of C)?

I'm only saying that when the people with the best credentials in the history of the universe on how to write RFC822-handling software all seem to agree that I shouldn't use procmail, I'm probably going to stop using procmail without demanding they explain their reasoning to me in detail.

Fundamental philosophical differences. I don't listen to any voice of authority asking me to change unless I can do my own exhaustive research and come to my own conclusions. (Hmm, where have we all recently had experiences with this dilemma?) Maybe that's why I rarely change anything, ever! Hah

I'd put more stock in the opinion of MUUGers (including yours) than rando wizzardz (hehe) on the interwebz.

You know that as well as anyone here - 99% of the programs we run on a daily basis aren't "safe" in either a theoretic (academic) or practical sense. GNU added enough features to it that I would think twice before suggesting even cat(1) is safe. But there are varying degrees of safety, and various approaches to it.

But aren't you then ruining your original argument that we shouldn't use procmail because "people" declare it unsafe? So then it becomes a matter of degrees and the level of "convincing" one is subjected to?

If unsafe -> discontinue use, and you just said vim -> unsafe, then you have just said vim -> discontinue use. Have you discontinued use of vim?

Er, say what? Run them on different ports, if they're all internal,

Nope, both sendmail and postfix are external-facing. The requirement is each IP appears to the world as its own box, with no trace or mention of the other (legal-ish privacy-ish reasons). Neither should send/receive through the other's IP. Postfix can do it, sendmail cannot. That was my problem.

You could avoid ssh by running a daemon with appropriate permissions on lo0 and aliasing to "|nc 127.0.0.1 12345".

Yup, I just dreamed up using a named pipe or similar last night. But then I'd still need to root to make sure the daemon auto-restarts if it dies. So not much better off, unless systemd has an unprivileged-user service concept now(? man that would be handy).

I'm not convinced you truly need multiple MTAs in the sense you suggest, but I'm not in your shoes so it's possible - in which case you have my sympathy :).

Ya, trust me, I explored every avenue (short of VMs; though maybe there's a container / jail way?). The pain was great, but the pill has been swallowed so no sense finding a "better" solution now. Well, at least until my sendmail+postfix twinning blows up due to RHEL clamping down on the thumbscrews. But at least I'll have a relatively painfree option of just twinning my postfix config and ditching sendmail (or sendmail will have the outgoing IP configurable by then).

Ohhhh yeah, if you need two different MTAs on the same RH or even Deb-based system, I would recommend installing the 2nd (and subsequent, if any) from source just to avoid having them fight over who gets to be the system MTA on every package update.

Turns out it wasn't a problem. The /etc/alternatives setup and interesting use of options in postfix make it update-proof. At least until we bump up a major RHEL version number. It was quite hard and interesting with no guarantee of success, but it worked 100% in the end with no downsides I can see; besides being insane. If anyone other than me ever wanted to do such a thing (never gonna happen) I'd do a presentation on it. :-) I found zero people actually attempting or accomplishing the feat on the net, so not much help there.

You are possibly the only person I would ever /recommend/ use git! I absolutely believe it's a good fit for your brain! Every time I have to use git for anything non-trivial, though, I am equally-absolutely guaranteed to leave work with a headache at least 3 days in a row, usually more like 2 weeks. If git works for you, great, meanwhile I'll be over here installing RCS.

Oh git still gives me major headaches, whenever I have to do something I haven't done yet and have a thin grasp of how to achieve it. I've learned that you hair-pull for a while to get a new thing done, then save the invocation in your cheatsheet. The grokking part seeps in later.

Remember "crash your system in 2 keystrokes, or less"? Ya, git feels a lot like that; but there's almost always an "out" -- the key is finding it...

I've found the git books (of which I have many) teach you all this stuff about the node graphs and such that turns out to be near useless for actually using the thing to just dev, save and push. Though I guess at some level knowing the guts actually makes the final grokking possible. Hard to say.

I like RCS. But RCS can't possibly do all the git does for me now. You'd probably be impressed (or dumbfounded?): 2 levels of libraries, and app, a "super-app" on top of that app, all with git-subtrees, 2 apps with 4 deployments (dev, test, demo, live) each. Everything is a git push away from having the latest version, including an automated db schema updater. My dev is now warp speed and I spend no time at all on db syncing or deployment. A new app on the libraries can be made in an hour by a clone and adjusting a conf file or two (mostly paths and url prefix). Who used to have the slogan "now you're playing with power".

Sorry to bear this bad news, but yeah, the same behaviour applies for aliases "|" execution.

Damn.

No rationale as yet, but it happens in set_ugid.c: https://github.com/vdukhovni/postfix/blob/master/postfix/src/util/set_ugid.c

Thanks for the link. I love short and sweet source files. There's the lame setgroups in there just staring at me, mocking, doing apparently nothing useful.

it's essentially been there forever. And nary a mention in the HISTORY file about why.

I have faith you'll eventually find the original argument you read a hundred years ago. Gotta be somewhere.

I'm in agreement with you here, it seems unhelpful, so hopefully someone else here can explain why secondary groups are *so* bad for security they need to be nuked from orbit?

That's a great question for all MUUGers to ponder. Maybe someone has an idea. I mean we can all agree the smell (as you say) seems to be on the right track, but here's my real world pain point in opposition to it, as well as upsetting the "don't surprise the user" dictum. Sitting here right now I can't really thing of a really-possible security issue caused by keeping the groups intact. I'll ponder it further in my sleep.

The sendmail people obviously didn't consider this a "bug", unless they really just never thought of it.

As such, if the braintrust of MUUG can't imagine a reason, it may be productive to open a postfix bug/featurereq for it. At least that might make the devs justify the original choice.

On 2023-04-19 Gilbert Detillieux wrote:

They may have had users like me in mind, who (over time) need to be added to over 16 separate secondary groups (yeah, I was running into that RPC AUTH_SYS 16-group limit in NFS, long before there was a simple fix).

Which makes me wonder... is there any command line program (or shell option) that lets a normal user *drop* their supplemental groups? I don't see one. You can change your primary group with newgrp/sg, but the tools don't seem to let you manipulate supplemental groups. Which further leads me to believe that no one in the *NIX world thinks dropping groups is a worthwhile, good or needed idea.

Furhter, perl doesn't seem to give you anything to manipulate this in core either, which I find really strange. perl usually lets you do *all* of this user/group system stuff, even if only through vaguely named special vars: $) anyone? (Ok, ya they now have pretty names too. But if modern much-vaunted jquery can do $() then I can have my $) thank you very much. <smirk>) So that leads me to believe perl-people think the idea is useless.

I was going to say postfix could let the user decide by running /bin/dg (which I'm coining just now, drop-groups) before their desired command. That would be more unix-y by letting the user decide and chain commands as they see fit.

Oh ya, I realized ACLs could probably also solve my root problem. But I don't think I'll ever stoop to using ACLs on Linux. I eradicate them everywhere I see them. Evil!