Subject: bug#77862: guix-daemon run as non-root sets up /etc/group incorrectly in build container

From: keinflue <[email-masked]>
Date: Fri, 06 Jun 2025 20:34:34 +0000

Hi,

I have been busy the last weeks. I might be able to continue looking at 
this next week. I can however report that my system build did not 
encounter any other packages with the same problem, other than the ones 
I already mentioned. However, the build also didn't fully succeed for 
other reasons. I learned that my approach to use a guix shell container 
with a modified store name to rebuild everything in a completely 
separate guix-daemon and store instance does not work that well. Some 
things simply don't work independently of the unprivileged daemon.

Best,
keinflue

On 06.06.2025 17:38, Ludovic Courtès wrote:
> Hello!
> 
> Reepca Russelstein <[email-masked]> writes:
> 
>> So if you'll bear with the extreme awkwardness, we could fork a helper
>> process immediately prior to calling unshare, which, upon receiving a
>> notification, will initialize the parent process's user namespace.  
>> Note
>> that the naming here is going to be inverted for process ancestry and
>> user namespace ancestry: the child process is in the parent user
>> namespace, and the parent process is in the child user namespace.
> 
> User namespaces seem to be an infinite supply of awkwardness!
> 
> I pushed a branch that implements those changes and actually works:
> 
>   https://codeberg.org/guix/guix/pulls/452
> 
> I marked it as WIP because I’m still in the process of updating the
> ‘guix’ package so I can actually run all the guix-daemon system tests
> and there may be some adjustments to be made, such as ensuring that
> ‘newgidmap’ is found both on Guix System and on Debian.
> 
> Next step would be to run the test suites of Coreutils, Go, and Python
> as keinflue did but I don’t have a good setup for that.
> 
> Thanks,
> Ludo’.