bug#50916: Experimental `guix container PID program args` not working as expected

bug#50916: Experimental `guix container PID program args` not working as expected

[Bonface Munyoki K.]

[-- Attachment #1: Type: text/plain, Size: 2382 bytes --]

Hi Guix!

I've tried running a redis server in a container,
and interact with it from outside the container as
such:

--8<---------------cut here---------------start------------->8---
guix environment --ad-hoc --container redis coreutils
--8<---------------cut here---------------end--------------->8---

Thereby, when I get the PID of the above running
process, I expect that:

--8<---------------cut here---------------start------------->8---
guix container PID redis-server --version
--8<---------------cut here---------------end--------------->8---

to be the redis version from the container which
is *6.2.4*. However, the command gets the
underlying redis-server from the host-- an old
Debian distribution-- which is at *3.2.6*.

In a bid to troubleshoot this, I have tried
running:

--8<---------------cut here---------------start------------->8---
guix container PID /bin/sh
--8<---------------cut here---------------end--------------->8---

which returns a shell from /outside/ the
container. Also, I have tried:

--8<---------------cut here---------------start------------->8---
guix environment --ad-hoc --container --link-profile
--8<---------------cut here---------------end--------------->8---

outside the $HOME directory, and then later:

--8<---------------cut here---------------start------------->8---
guix container PID echo $GUIX_ENVIRONMENT
--8<---------------cut here---------------end--------------->8---

with the expectation that $GUIX_ENVIRONMENT will
output some path from the store. However, I get
nothing. Finally, I tried:

--8<---------------cut here---------------start------------->8---
guix container exec PID ps aux
--8<---------------cut here---------------end--------------->8---

to gain perspective of whether I see the processes
from the host's or container's perspective. That
command, at least on my end, clearly shows that I
am seeing things from the host's perspective. This
demonstrates that *guix container* as described in
https://guix.gnu.org/manual/en/html_node/Invoking-guix-container.html
doesn't not execute from the container; and as
such is a bug.

-- 
Bonface M. K.
D4F09EB110177E03C28E2FE1F5BBAE1E0392253F (hkp://keys.gnupg.net)
Free Software Activist
Humble GNU Emacs User | Bearer of scheme-y parens
Curator: <https://upbookclub.com> | Twitter: @BonfaceKilz

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 865 bytes --]

bug#50916: Experimental `guix container PID program args` not working as expected

[kiasoc5]

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.