Daemon Running as Root

When guix-daemon runs as root, you may not want package build processes themselves to run as root too, for obvious security reasons. To avoid that, a special pool of build users should be created for use by build processes started by the daemon. Having several such users allows the daemon to launch distinct build processes under separate UIDs, which guarantees that they do not interfere with each other—an essential feature since builds are regarded as pure functions (voir Introduction).

Sur un système GNU/Linux, on peut créer une réserve de comptes de construction comme ceci (avec la syntaxe Bash et les commandes shadow) :

# groupadd --system guixbuild
# for i in $(seq -w 1 10);
  do
    useradd -g guixbuild -G guixbuild           \
            -d /var/empty -s $(which nologin)    \
            -c "Compte de construction Guix $i" --system    \
            guixbuilder$i;
  done

Le nombre de comptes de construction détermine le nombre de tâches de constructions qui peuvent tourner en parallèle, tel que spécifié par l’option --max-jobs (voir --max-jobs). Pour utiliser guix system vm et les commandes liées, vous devrez ajouter les comptes de construction au groupe kvm pour qu’ils puissent accéder à /dev/kvm avec -G guixbuild,kvm plutôt que -G guixbuild (voir Invoquer guix system).

Le programme guix-daemon peut ensuite être lancé en root avec la commande suivante⁶ :

# guix-daemon --build-users-group=guixbuild

In this setup, /gnu/store is owned by root.

Daemon Running Without Privileges

The second and preferred option is to run guix-daemon 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 use 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 (voir Installation binaire).

When using this option, you only need to create one user account, and guix-daemon will run with the authority of that account:

# groupadd --system guix-daemon
# useradd -g guix-daemon -G guix-daemon              \
          -d /var/empty -s $(which nologin)          \
          -c "Guix daemon privilege separation user" \
          --system guix-daemon

In this configuration, /gnu/store is owned by the guix-daemon user.

The Isolated Build Environment

In both cases, the daemon starts build processes without privileges in an isolated or hermetic build environment—a “chroot”. On GNU/Linux, by default, the build environment contains nothing but:

• un répertoire /dev minimal, créé presque indépendamment du /dev de l’hôte⁷ ;
• le répertoire /proc ; il ne montre que les processus du conteneur car on utilise une espace de nom séparé pour les PID ;
• /etc/passwd avec une entrée pour le compte actuel et une entrée pour le compte nobody ;
• /etc/group avec une entrée pour le groupe de ce compte ;
• /etc/hosts avec une entrée qui fait correspondre localhost à 127.0.0.1 ;
• un répertoire /tmp inscriptible.

Le chroot ne contient pas de dossier /home, et la variable d’environnement HOME est initialisée au répertoire /homeless-shelter inexistant. Cela permet de mettre en valeur les utilisations inappropriées de HOME dans les scripts de construction des paquets.

All this is usually enough to ensure details of the environment do not influence build processes. In some exceptional cases where more control is needed—typically over the date, kernel, or CPU—you can resort to a virtual build machine (voir virtual build machines).

Vous pouvez influencer le répertoire où le démon stocke les arbres de construction via la variable d’environnement TMPDIR. Cependant, l’arbre de construction dans le chroot sera toujours appelé /tmp/guix-build-nom.drv-0, où nom est le nom de la dérivation — p.ex., coreutils-8.24. De cette façon, la valeur de TMPDIR ne fuite pas à l’intérieur des environnements de construction, ce qui évite des différences lorsque le processus de construction retient le nom de leur répertoire de construction.

Le démon prend aussi en compte la variable d’environnement https_proxy pour ses téléchargements HTTP et HTTPS, que ce soit pour les dérivations à sortie fixes (voir Dérivations) ou pour les substituts (voir Substituts).