Operations such as building a package or running the garbage collector
are all performed by a specialized process, the Guix daemon, on
behalf of clients. Only the daemon may access the store and its
associated database. Thus, any operation that manipulates the store
goes through the daemon. For instance, command-line tools such as
guix package and
guix build communicate with the
daemon (via remote procedure calls) to instruct it what to do.
In a standard multi-user setup, Guix and its daemon—the
guix-daemon program—are installed by the system
administrator; /nix/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" guix-builder$i; done
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 the
Guix may also be used in a single-user setup, with
running as an unprivileged user. However, to maximize non-interference
of build processes, the daemon still needs to perform certain operations
that are restricted to
root on GNU/Linux: it should be able to
run build processes in a chroot, and to run them under different UIDs.
To that end, the
nix-setuid-helper program is provided; it is
a small C program (less than 300 lines) that, if it is made setuid
root, can be executed by the daemon to perform these operations
on its behalf. The
root-owned /etc/nix-setuid.conf file
is read by
nix-setuid-helper; it should contain exactly two
words: the user name under which the authorized
runs, and the name of the build users group.
If you are installing Guix as an unprivileged user and do not have the
ability to make nix-setuid-helper setuid-
root, 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.
On some systems
/dev/shm, which supports
shared memory, is a symlink to another directory such as
/run/shm, that is not is the chroot. When that is the
case, shared memory support is unavailable in the chroot environment.
The workaround is to make sure that /dev/shm is directly a
tmpfs mount point.