Suivant: , Monter: Paramétrer le démon   [Table des matières][Index]


2.2.1 Réglages de l’environnement de construction

In a standard multi-user setup, Guix and its daemon—the guix-daemon program—are installed by the system administrator. Unprivileged users may use Guix tools to build packages or otherwise access the store, and the daemon will do it on their behalf, ensuring that the store is kept in a consistent state, and allowing built packages to be shared among users.

There are currently two ways to set up and run the build daemon:

  1. running guix-daemon as “root”, letting it run build processes as unprivileged users taken from a pool of build users—this is the historical approach;
  2. running guix-daemon as a separate unprivileged user, relying on Linux’s unprivileged user namespace functionality to set up isolated environments—this is the option chosen when installing Guix on a systemd-based distribution with the installation script (voir Installation binaire).

The sections below describe each of these two configurations in more detail and summarize the kind of build isolation they provide.

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 suivante6 :

# 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:

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).


Notes de bas de page

(6)

Si votre machine utilise le système d’initialisation systemd, copiez le fichier prefix/lib/systemd/system/guix-daemon.service dans /etc/systemd/system pour vous assurer que guix-daemon est démarré automatiquement. De même, si votre machine utilise le système d’initialisation Upstart, copiez le fichier prefix/lib/upstart/system/guix-daemon.conf dans /etc/init.

(7)

« presque », parce que même si l’ensemble des fichiers qui apparaissent dans le /dev du chroot sont déterminés à l’avance, la plupart de ces fichiers ne peut pas être créée si l’hôte ne les a pas.


Suivant: Utiliser le dispositif de déchargement, Monter: Paramétrer le démon   [Table des matières][Index]