GNU bug report logs - #77862
guix-daemon run as non-root sets up /etc/group incorrectly in build container

Previous Next

Package: guix;

Reported by: keinflue <keinflue <at> posteo.net>

Date: Thu, 17 Apr 2025 11:22:03 UTC

Severity: important

Full log


Message #43 received at 77862 <at> debbugs.gnu.org (full text, mbox):

From: keinflue <keinflue <at> posteo.net>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 77862 <at> debbugs.gnu.org
Subject: Re: guix-daemon run as non-root sets up /etc/group incorrectly in
 build container
Date: Sat, 03 May 2025 02:16:40 +0000
[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.