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

Previous Next

Full log

Message #23 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, 15 Jul 2025 11:36:42 +0200

Hi,

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

> Ludovic Courtès <ludovic.courtes <at> inria.fr> writes:
>
>> But it’s unsatisfactory: I would hope the unprivileged daemon would
>> allow us to address that shortcoming.
>
> Yes it does, as long as the needed syscalls are not restricted. I'm not
> sure when this will change with Docker [1].
>
>>> I don't think the isolated build environment is possible when
>>> `unshare' is not allowed and the UID is not 0 (except by using
>>> something like PRoot), right?
>>
>> What I meant is that there’s only one ‘unshare’ call, which is necessary
>> from a security viewpoint but not from a functional viewpoint.  Offering
>> an option to skip it in contexts where the tradeoff is acceptable could
>> help maybe?
>
> Ah sorry, I was conflating `unshare` and `clone`. The default Docker
> seccomp profile [2] of course also blocks (among other flags)
> CLONE_NEWUSER (0x10000000) for the `clone` syscall without
> CAP_SYS_ADMIN, using SCMP_CMP_MASKED_EQ. This also leads to EPERM being
> returned.

Oh OK.

> [1] https://github.com/moby/moby/issues/42441
> [2] https://github.com/moby/moby/blob/master/profiles/seccomp/default.json

So hmm, it looks like in practice we’re left with no choice but to keep
using ‘--disable-chroot’ in Docker?

Do you happen to know what people running Docker-in-Docker (or similar)
do?

Thanks,
Ludo’.

Previous Next

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