GNU bug report logs - #77862
guix-daemon run as non-root sets up /etc/group incorrectly in build container

Previous Next

Full log

View this message in rfc822 format

From: keinflue <keinflue <at> posteo.net>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 77862 <at> debbugs.gnu.org
Subject: bug#77862: guix-daemon run as non-root sets up /etc/group incorrectly in build container
Date: Sat, 26 Apr 2025 11:08:57 +0000

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.