GNU bug report logs -
#75810
[PATCH 0/6] Rootless guix-daemon
Previous Next
Reported by: Ludovic Courtès <ludo <at> gnu.org>
Date: Fri, 24 Jan 2025 17:24:02 UTC
Severity: normal
Tags: patch
Done: Ludovic Courtès <ludo <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
Hi,
On Fri, 28 Feb 2025 at 15:29, Ludovic Courtès <ludo <at> gnu.org> wrote:
> * doc/guix.texi (Build Environment Setup): Reorganize a bit. Add
> section headings “Daemon Running as Root” and “The Isolated Build
> Environment”. Add “Daemon Running Without Privileges” subsection.
> Remove paragraph about ‘--disable-chroot’.
> (Invoking guix-daemon): Warn against ‘--disable-chroot’ and explain why.
> ---
> doc/guix.texi | 100 +++++++++++++++++++-------
[...]
> diff --git a/doc/guix.texi b/doc/guix.texi
> index 93380dc30d4..a2b65299e9f 100644
> --- a/doc/guix.texi
> +++ b/doc/guix.texi
> @@ -877,6 +877,7 @@ Setting Up the Daemon
> @section Setting Up the Daemon
[...]
> +There are currently two ways to set up and run the build daemon:
> +
> +@enumerate
> +@item
> +running @command{guix-daemon} as ``root'', letting it run build
> +processes as unprivileged users taken from a pool of build users---this
> +is the historical approach;
> +
> +@item
> +running @command{guix-daemon} as a separate unprivileged user, relying
> +on Linux's @dfn{unprivileged user namespace} functionality to set up
> +isolated environments---this option only appeared recently.
> +@end enumerate
> +
> +The sections below describe each of these two configurations in more
> +detail and summarize the kind of build isolation they provide.
The paragraph above could give the impression that there is a choice
between two options – well it was my understand when reading. On
foreign distro, there is no option, IIUC.
Therefore, I would clarify, something like:
Depending on your situation, the build daemon can set up and run in
different ways:
@enumerate
@item
running @command{guix-daemon} as ``root'', letting it run build
processes as unprivileged users taken from a pool of build
users---this is the historical approach;
@item
running @command{guix-daemon} as a separate unprivileged user,
relying on Linux's @dfn{unprivileged user namespace}
functionality to set up isolated environments---this option is
recently become mandatory on foreign distribution.
@end enumerate
The sections below describe each of these two configurations in more
detail and summarize the kind of build isolation they provide.
Somehow, I would explicitly mention here what are my options when using
Guix System and what is my option when using foreign distro.
> +@unnumberedsubsubsec Daemon Running Without Privileges
> +
> +@cindex rootless build daemon
> +@cindex unprivileged build daemon
> +@cindex build daemon, unprivileged
> +The second option, which is new, is to run @command{guix-daemon}
I would remove “which is new”.
> +@emph{as an unprivileged user}. It has the advantage of reducing the
> +harm that can be done should a build process manage to exploit a
> +vulnerability in the daemon. This option requires the user of Linux's
> +unprivileged user namespace mechanism; today it is available and enabled
> +by most GNU/Linux distributions but can still be disabled.
> The
> +installation script automatically determines whether this option is
> +available on your system (@pxref{Binary Installation}).
I would write: When using the installation script, it automatically
determines whether …
> -If you are installing Guix as an unprivileged user, it is still possible
> -to run @command{guix-daemon} provided you pass @option{--disable-chroot}.
> -However, build processes will not be isolated from one another, and not
> -from the rest of the system. Thus, build processes may interfere with
> -each other, and may access programs, libraries, and other files
> -available on the system---making it much harder to view them as
> -@emph{pure} functions.
> -
Yeah, good removal! :-)
Cheers,
simon
This bug report was last modified 56 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.