GNU bug report logs -
#77862
guix-daemon run as non-root sets up /etc/group incorrectly in build container
Previous Next
Full log
Message #43 received at 77862 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi,
On 02.05.2025 17:38, Ludovic Courtès wrote:
> Hello,
>
> keinflue <keinflue <at> posteo.net> 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’.
[coreutils.diff (text/x-patch, attachment)]
This bug report was last modified 9 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.