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 <keinf...@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’.
