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

[Gilbert Detillieux]

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

-- 
Gilbert Detillieux          E-mail: Gilbert.Detillieux at umanitoba.ca
Computer Science            Web:    http://cs.umanitoba.ca/~gedetil/
University of Manitoba
Winnipeg MB CANADA  R3T 2N2
For best CS dept. service, contact <cs-support at lists.umanitoba.ca>.