Subject: [bug#75810] [PATCH 0/6] Rootless guix-daemon

From: Reepca Russelstein <[email-masked]>
Date: Thu, 13 Mar 2025 01:04:09 -0500

Ludovic Courtès <[email-masked]> writes:

> I tried running a build that sleeps and then joining its namespaces but
> failed:
>
> $ pgrep -fa builder
> 16091 guile --no-auto-compile -L /home/ludo/src/guix/test-tmp/store/ngrj4gl9lrbmbklcsbgcrq622n9nf0jw-module-import -C /home/ludo/src/guix/test-tmp/store/cskis66zjnhk28h11lbaxkd3j9lyzz6a-module-import-compiled /home/ludo/src/guix/test-tmp/store/akndbdx1lmnigf8bi29dr0vd3c8dbdrg-attempt-to-unmount-input-builder
> $ nsenter -m -u -i -n -p -U  -t 16091 
> nsenter: reassociate to namespace 'ns/ipc' failed: Operation not permitted
> $ guix container exec 16091 /bin/sh
> guix container: error: setns: 7 0: Operation not permitted
> guix container: error: process exited with status 1

I failed to take into account that the setns sequence needs to start by
joining the user namespace that owns all the other namespaces, so as to
gain the necessary capabilities for joining them.  But after unshare
creates the second user namespace, that first user namespace no longer
has a process in it; it only still exists due to indirect references.
Without a process to reference it by, we can't join it.  Trying to join
the user namespace of the builder instead joins the inner user
namespace, then tries to use the acquired credentials to join the
namespaces owned by the outer user namespace, which naturally fails.

> If you can think of ways to do that, I’m all ears.  :-)

It looks like the only easy way to test this - aside from something like
scripted gdb playthroughs - might legitimately be to include a test
inside the daemon itself.

> You can try from the ‘wip-rootless-daemon’ at
> <https://codeberg.org/civodul/guix> and apply the patch I sent earlier.
>
> (Incidentally, I don’t think we could write an automated test for that;
> in theory we could use (guix scripts processes) to determine the PID of
> the build process but that would be too brittle, especially when running
> “make check -j123” where it could pick the wrong guix-daemon process.)

If we included a randomly-generated string in the command line or
environment of something in the build environment, and then went looking
through /proc for the matching process, it could work.  But it's moot if
we put this particular test inside the daemon.

- reepca