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
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.
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
# groupadd guix-builder # for i in `seq 1 10`; do useradd -g guix-builder -G guix-builder \ -d /var/empty -s `which nologin` \ -c "Guix build user $i" --system \ guix-builder$i; done
The /gnu/store directory (or whichever was specified with the
--with-store-dir option) must have ownership and permissions as
# chgrp guix-builder /gnu/store # chmod 1775 /gnu/store
guix-daemon program may then be run as
# guix-daemon --build-users-group=guix-builder
This way, the daemon starts build processes in a chroot, under one of
guix-builder users. On GNU/Linux, by default, the chroot
environment contains nothing but:
/devdirectory, created mostly independently from the host
/procdirectory; it only shows the container’s processes since a separate PID name space is used;
If you are installing Guix as an unprivileged user, it is still
possible to run
guix-daemon. 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.
“Mostly”, because while the set of files
that appear in the chroot’s
/dev is fixed, most of these files
can only be created if the host has them.