This bug still persists and effectively bypasses container sandboxing: 1. Start a container shell.
$ guix shell --container 2. Exec a shell inside the container. Here it is a foreign distro's bash, and assume that there is only 1 container running. $ guix container exec $(pgrep --full 'guix shell --container') /bin/bash 3. Observe that path is not empty. $ echo $PATH /usr/local/sbin:/usr/local/bin:/usr/bin This shell can access commands outside the container, such as kill (part of util-linux). 4. Kill the container from the shell inside the container. [env] $ kill -9 $(pgrep --full 'guix shell --container') [env] $ echo $? 0 The shell still persists in the container, even though the container itself is killed. The problem is that in guix/scripts/container/exec.scm, execlp is used to launch program with args. info guile says this about execlp: Similar to ‘execl’, however if FILENAME does not contain a slash then the file to execute will be located by searching the directories listed in the ‘PATH’ environment variable. As seen above $PATH is set to a subset of the host system's PATH, not the PATH inside the guix container.
