[RndTbl] "washing" a fork/exec to force all groups

[Adam Thompson]

> 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