Subject: bug#77862: guix-daemon run as non-root sets up /etc/group incorrectly in build container

From: keinflue <[email-masked]>
Date: Sat, 19 Apr 2025 11:18:51 +0000

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 <[email-masked]> 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’.