2.2.1 Build Environment Setup

In a standard multi-user setup, Guix and its daemon—the guix-daemon program—are installed by the system administrator; /gnu/store is owned by root and guix-daemon runs as root. 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.

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. These build users need not have a shell and a home directory: they will just be used when the daemon drops root privileges in build processes. 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 (see Introduction).

On a GNU/Linux system, a build user pool may be created like this (using Bash syntax and the shadow commands):

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

The number of build users determines how many build jobs may run in parallel, as specified by the --max-jobs option (see --max-jobs). To use guix system vm and related commands, you may need to add the build users to the kvm group so they can access /dev/kvm, using -G guixbuild,kvm instead of -G guixbuild (see Invoking guix system).

The guix-daemon program may then be run as root with the following command⁶:

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

This way, the daemon starts build processes in a chroot, under one of the guixbuilder users. On GNU/Linux, by default, the chroot environment contains nothing but:

• a minimal /dev directory, created mostly independently from the host /dev⁷;
• the /proc directory; it only shows the processes of the container since a separate PID name space is used;
• /etc/passwd with an entry for the current user and an entry for user nobody;
• /etc/group with an entry for the user’s group;
• /etc/hosts with an entry that maps localhost to 127.0.0.1;
• a writable /tmp directory.

The chroot does not contain a /home directory, and the HOME environment variable is set to the non-existent /homeless-shelter. This helps to highlight inappropriate uses of HOME in the build scripts of packages.

All this 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 (see virtual build machines).

You can influence the directory where the daemon stores build trees via the TMPDIR environment variable. However, the build tree within the chroot is always called /tmp/guix-build-name.drv-0, where name is the derivation name—e.g., coreutils-8.24. This way, the value of TMPDIR does not leak inside build environments, which avoids discrepancies in cases where build processes capture the name of their build tree.

The daemon also honors the http_proxy and https_proxy environment variables for HTTP and HTTPS downloads it performs, be it for fixed-output derivations (see Derivations) or for substitutes (see Substitutes).

If you are installing Guix as an unprivileged user, it is still possible to run guix-daemon provided you pass --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 pure functions.