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

[Trevor Cordes]

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