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

Previous Next

Full log

Message #25 received at 77862 <at> debbugs.gnu.org (full text, mbox):

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

I just realized that there is also need for special handling of 
/dev/kvm. When running with privileges it was possible to add the build 
users to the kvm group to get access to /dev/kvm in the build container.

To have this continue to work in unprivileged mode, the kvm group (or I 
guess more specifically the group of /dev/kvm) should be mapped in the 
user namespace and presumably should not be dropped from supplementary 
groups.

There is also /dev/tty in the container which has unmapped group 
ownership, although that doesn't prevent access to it.

Alternatively I guess all supplementary groups could be preserved, but 
they should then also all be mapped into the user namespace. Then the 
user would have to drop supplementary groups manually (if they are able 
to) before running guix-daemon if they do not want any of them to 
propagate into the build environment and can't create a new user 
specifically for that purpose (e.g. because they do not have root access 
on the machine).

On 19.04.2025 13:18, keinflue wrote:
> I can confirm that the patch resolves the particular failing test.
> 
> However I overlooked that there are other failing tests:
> 
>> FAIL: tests/chgrp/default-no-deref.sh
>> FAIL: tests/chgrp/no-x.sh
>> FAIL: tests/chgrp/posix-H.sh
>> FAIL: tests/chgrp/recurse.sh
>> FAIL: tests/chgrp/basic.sh
> 
> Here is an example of the failures:
> 
>> + require_membership_in_two_groups_
>> + test 0 = 0
>> + groups='30000 65534'
>> + case "$groups" in
>> + require_local_dir_
>> + require_mount_list_
>> + local 'mount_list_fail=cannot read table of mounted file systems'
>> + df --local
>> + grep -F 'cannot read table of mounted file systems'
>> + is_local_dir_ .
>> + test 1 = 1
>> + df --local .
>> + set _ 30000 65534
>> + shift
>> + g2=65534
>> + mkdir d
>> + touch f
>> + ln -s ../f d/s
>> ++ stat --printf=%g f
>> + g_init=30000
>> + chgrp -R 65534 d
>> chgrp: changing group of 'd/s': Invalid argument
>> chgrp: changing group of 'd': Invalid argument
>> + fail=1
>> ++ stat --printf=%g f
>> + test 30000 = 30000
>> + Exit 1
>> + set +e
>> + exit 1
>> + exit 1
>> + remove_tmp_
>> + __st=1
>> + cleanup_
>> + :
>> + test '' = yes
>> + cd /tmp/guix-build-coreutils-9.1.drv-0/coreutils-9.1
>> + chmod -R u+rwx 
>> /tmp/guix-build-coreutils-9.1.drv-0/coreutils-9.1/gt-default-no-deref.sh.AEHe
>> + rm -rf 
>> /tmp/guix-build-coreutils-9.1.drv-0/coreutils-9.1/gt-default-no-deref.sh.AEHe
>> + exit 1
>> FAIL tests/chgrp/default-no-deref.sh (exit status: 1)
> 
> I think this happens if the user running guix-daemon has supplementary
> groups. These are not mapped via /proc/gid_map in the build container
> and therefore are reported as the overflow gid (65534) by getgroups.
> 
> The test cases assume that they can change ownership to this
> additional group but that is not permitted on the overflow gid.
> 
> I think supplementary groups should be dropped in the user namespace
> for the build container to make the behavior reproducible.
> Unfortunately this may be impossible if the parent namespace has set
> /proc/[...]/setgroups to "deny".
> 
> Best,
> keinflue
> 
> On 17.04.2025 18:51, Ludovic Courtès wrote:
>> keinflue <keinflue <at> posteo.net> writes:
>> 
>>> Here are excerpts from the build log:
>> 
>> Thanks.
>> 
>>> Unfortunately I made a mistake and accidentally lost the container in
>>> which I tried this, so I can not verify right now whether the patch
>>> actually resolves the issue.
>>> 
>>> It might take me a day or two to restore it.
>> 
>> No worries, I’ll wait for your feedback.
>> 
>>> This happened either during or shortly after bootstrap builds, so I
>>> don't know whether this was the final coreutils package or one from
>>> commencement.scm.
>> 
>> OK.
>> 
>> If you have a setup for full rebuilds (no substitutes) running in a
>> container, I’m curious to learn more about it!
>> 
>> Ludo’.

Previous Next

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