Experimental `guix container PID program args` not working as expected

  • Open
  • quality assurance status badge
Details
2 participants
  • kiasoc5
  • Bonface Munyoki K.
Owner
unassigned
Submitted by
Bonface Munyoki K.
Severity
normal
B
B
Bonface Munyoki K. wrote on 30 Sep 2021 16:23
(address . bug-guix@gnu.org)
865yuif8go.fsf@bonfacemunyoki.com
Hi Guix!

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

Toggle snippet (3 lines)
guix environment --ad-hoc --container redis coreutils

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

Toggle snippet (3 lines)
guix container PID redis-server --version

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:

Toggle snippet (3 lines)
guix container PID /bin/sh

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

Toggle snippet (3 lines)
guix environment --ad-hoc --container --link-profile

outside the $HOME directory, and then later:

Toggle snippet (3 lines)
guix container PID echo $GUIX_ENVIRONMENT

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

Toggle snippet (3 lines)
guix container exec PID ps aux

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
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
-----BEGIN PGP SIGNATURE-----

iQJKBAEBCAA0FiEE1PCesRAXfgPCji/h9buuHgOSJT8FAmFVyGoWHG1lQGJvbmZh
Y2VtdW55b2tpLmNvbQAKCRD1u64eA5IlP73JEACLIxdzdXK+cNwFL66h6hSvg5ZM
C2hlrSiuS3AyqThpM9NFXy+EZfFreRRGAsBNlnwbhLQx6keMGCCqdMEIORdLe2Sq
8J+Mne8QyUokMzHBKKuNwglnRBFlPz1jiBoYNyGyYyXGWX/Dfg+l77uEDtSebHj7
z+yH/6EiO2b2eXMmhWb6znP3X3gsTMJXFC5UOHYmOGIBZtKVHed07s1cPzppuY/8
iD5KJpN7xGj7TkmPQW9uYbov2GVROQDY2gjBC5BCVLiIDQ+8gcwWXl1m2l6UxHlA
QhfRVcCZma3DnNA6pZcwMg5bOdM2WBEghmC3TqFD9XReFKHpegWSUmjxiw/mhMQa
KtP2pGjqbKNWkgRSSjtEyee6AuslzLgzyVMqebzPkTbT37dnnaC7P/UAZgbNGmGV
tdamBg7OHEUTe1VwuM6gsJctMsjqg6Olm1cDN+HPu8/8AnItnxOMYjxIcwfzGhxR
XSW07XNXj6BE2B4FkEZ/R4JqBpBMtAMUgmKE8plsnF3R/Swdo3RS3klGageXG+HR
LM88oMmu+GGduJDkmNKI8RDfn9ZSBImwolPmwVjEXV4k5dqg0xFKz5utSMzZWhyL
X+sohIWJFh/RrGsHv3z26zOUAMO5Fi7j1Cgr7bns3PUC8XvDi7v/NCHhympBnxYn
SLkx0tZ1q9SPZkiiVg==
=59kr
-----END PGP SIGNATURE-----

K
K
kiasoc5 wrote on 6 Aug 2022 21:56
20220806195629.054aef70@aria
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.
?