GNU bug report logs - #50916
Experimental `guix container PID program args` not working as expected

Previous Next

Package: guix;

Reported by: Bonface Munyoki K. <me <at> bonfacemunyoki.com>

Date: Thu, 30 Sep 2021 14:24:01 UTC

Severity: normal

Full log


Message #8 received at 50916 <at> debbugs.gnu.org (full text, mbox):

From: kiasoc5 <kiasoc5 <at> disroot.org>
To: me <at> bonfacemunyoki.com, 50916 <at> debbugs.gnu.org
Subject: bug#50916: Experimental `guix container PID program args` not
 working as expected
Date: Sat, 6 Aug 2022 19:56:29 +0000
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.




This bug report was last modified 2 years and 315 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.