Hi,
On 26.04.2025 10:50, Ludovic Courtès wrote:
If there is no supplementary group reported by getgroups at all, then
coreutils just skips the test and it is ok again. Probably the
coreutils test case should remove any gid reported by getgroups that
is equal to the overflow gid before making that decision.
Dropping all supplementary groups from the build process (after
unshare and before writing "deny" to /proc/pid/setgroups) would make
it so that this test case is always skipped by having getgroups only
report 30000, however that would also drop the kvm group as mentioned
above and is also not permitted in all environments (e.g. when the
parent namespace already set /proc/[pid]/setgroups to "deny").
So I think that instead either all supplementary groups of the user or
at least the kvm group specifically needs to be mapped via
/proc/[pid]/gid_map. When doing so getgroups would report 30000 and
984 (assuming identity gid map for 984) in your test case above and
the coreutils test case would work again, because
chgrp 984 testfile
would then succeed with 984 mapping back to the host namespace to a
supplementary group of the process.
Having reread user_namespaces(7), I don’t think we can change the set
of
supplementary groups at all: that effectively requires root privileges.
So the best we can do is map the “kvm” group inside the user namespace.
I also had another look and I missed that effectively CAP_SETGID is
required in the _parent_ namespace in order to use setgroups (because
otherwise writing "deny" to /proc/[pid]/setgroups is essentially
forced).
But the same seems to also be required to map more than the own
effective uid/gid of the process into the namespace.
Mapping more uids/gids is otherwise usually handled by a setuid utility
(newuidmap, newgidmap) I think.
So I guess neither solution of dropping or mapping supplementary groups
will work completely unprivileged and the only solution is to modify or
disable the coreutils test case.
And mapping only kvm wouldn't be sufficient either, unless only that
specific group would be supported. All supplementary groups of the
process must be mapped for the test case to succeed (or at least one of
them, I haven't checked by which rule the test cases chooses the gid for
the test scenario from among the supplementary gids).
Best,
keinflue
