Correction: I meant /proc/sys/kernel/overflowgid instead of
/proc/sys/fs/overflowgid. I think these two can be modified
independently even if they have the same default value.
On 03.05.2025 15:38, keinflue wrote:
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
