Hello,

noticed this on guix (https://issues.guix.gnu.org/77862#5) when building coreutils 9.1.

Some of the gnulib test cases may fail for this package in test-chown.h and test-lchown.h when building in an unprivileged user namespace on Linux:

FAIL: test-chown
================

test-chown.h:156: assertion 'func (BASE "dir/link2", -1, gids[1]) == 0' failed
FAIL test-chown (exit status: 134)

FAIL: test-fchownat
===================

test-chown.h:156: assertion 'func (BASE "dir/link2", -1, gids[1]) == 0' failed
FAIL test-fchownat (exit status: 134)

[...]

FAIL: test-lchown
=================

test-lchown.h:174: assertion 'func (BASE "dir/link2", -1, gids[1]) == 0' failed
FAIL test-lchown (exit status: 134)

The problem is that a supplementary group of the build process which is not mapped into the user namespace via /proc/[pid]/gid_map will be reported as the overflow gid (by default 65534) in the user namespace and the test cases have no special handling of this gid. The test cases attempt to change ownership to this supplementary gid, which for other supplementary gids is normally permitted even for an unprivileged user. However, for the unmapped overflow gid specifically this is not the case and will result in EINVAL.

This was noticed during experimentation with Guix's new feature to run the build daemon as unprivileged user process, which relies on unprivileged user namespaces to construct the build container. As discussed in the linked issue it isn't really an option to drop the supplementary groups in this setting.

I think the test cases should remove the overflow gid (ideally the actual value obtained from /proc/sys/fs/overflowgid) from the obtained list of gids before further processing.

A similar issue occurred with coreutils' own test cases and has already been fixed, see https://debbugs.gnu.org/cgi/bugreport.cgi?bug=78225.

Unfortunately I wasn't able to reproduce the issue with a standalone build of gnulib. I think the guix package does not run the test cases. I do not see any changes on main that would prevent this from occurring.

Best,
keinflue

Reply via email to