GNU bug report logs - #77900
Unprivileged guix-daemon fails to build in Docker/relocatable pack

Previous Next

Full log

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

From: Ludovic Courtès <ludovic.courtes <at> inria.fr>
To: David Elsing <david.elsing <at> posteo.net>
Cc: 77900 <at> debbugs.gnu.org, Reepca Russelstein <reepca <at> russelstein.xyz>
Subject: Re: Unprivileged guix-daemon fails to build in Docker/relocatable pack
Date: Tue, 08 Jul 2025 10:08:50 +0200

Hi David,

Cc: Reepca.

David Elsing <david.elsing <at> posteo.net> writes:

> Ludovic Courtès <ludovic.courtes <at> inria.fr> writes:
>
>> When running guix-daemon unprivileged in Docker (or, similarly, in a
>> ‘guix pack -R’ relocatable pack), it fails to spawn the build process:
>> [...]
>> The clone(2) man page lists two reasons for getting EPERM with
>> CLONE_NEWUSER:
>
> I'm not sure about `guix pack -R', but I think in the default Docker
> seccomp profile, the unshare system call [1] requires CAP_SYS_ADMIN,
> otherwise EPERM is also return. I just tested the Docker seccomp profile
> with podman, and indeed the unshare command fails because the unshare
> system call returns EPERM. Maybe you can try with
> "--security-opt=seccomp=unconfined"?

Oh I see, thanks for chiming in.

I don’t actually use podman and Docker but I think it would be nice if
the unprivileged guix-daemon would work out of the box in these
environments, particularly in CI environments like GitLab-CI where
passing ‘--security-opt=seccomp=unconfined’ is not an option.

We can ‘unshare’ only once, to lock the mounts inside the build
environment.  If that’s the only issue, we could add a command-line
option to disable that or perhaps even detect that we’re in such an
environment and disable it automatically.

WDYT?

Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.