Hi, On 02.05.2025 17:38, Ludovic Courtès wrote: > Hello, > > keinflue writes: > >> I also had another look and I missed that effectively CAP_SETGID is >> required in the _parent_ namespace in order to use setgroups (because >> otherwise writing "deny" to /proc/[pid]/setgroups is essentially >> forced). >> >> But the same seems to also be required to map more than the own >> effective uid/gid of the process into the namespace. > > Right, user_namespaces(7) makes it clear: > > • The data written to uid_map (gid_map) must consist of a sin‐ > gle line that maps the writing process's effective user ID > (group ID) in the parent user namespace to a user ID (group > ID) in the user namespace. > >> So I guess neither solution of dropping or mapping supplementary >> groups will work completely unprivileged and the only solution is to >> modify or disable the coreutils test case. > > Yes, I came to this conclusion as well. > > I believe the attached Coreutils patch should fix that (yet to be > tested). Would be worth reporting upstream as well because in a way > it’s a failure of the test framework. I tried to test the patch: I had trouble with the normal origin patches mechanism. The first failing coreutils package is coreutils-final from commencement.scm and I didn't manage to properly replace that package without a dependency on the unpatched package remaining. Instead I wrote an equivalent substitute* in a post-unpack phase. The test cases mentioned earlier now succeeded, but another testsuite for gnulib (also as part of coreutils) failed afterwards. The failure cause is the same, except this time written in C sources. I also fixed that via substitute* clauses. See attached patch. This unfortunately causes rebuilds of the coreutils-mesboot (and coreutils-boot0) packages as well, although those do not perform the tests. It seems that now the system build proceeds much further (still running). I will see whether I can report the issue(s) upstream to coreutils and gnulib. I noticed that in coreutils 9.2 (guix is currently 9.1) a similar fix was applied to handle special gids on MacOS. Unfortunately the default Linux overflow gid is not included in that list. In any case, the patch needs to be adjusted for newer coreutils versions. > > Thanks, > Ludo’.