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.
Try without the strace, but see what groups you get by running "id" as a child command under the influence of "newgrp" (or "sg", which I wasn't aware of until you pointed it out).
Gilbert
On 2023-04-18 3:59 a.m., Trevor Cordes wrote:
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...