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

Debbugs page

Bonface Munyoki K. wrote 3 years ago
(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-----

kiasoc5 wrote 3 years ago
(address . me@bonfacemunyoki.com)(address . 50916@debbugs.gnu.org)
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.
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 50916@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 50916
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch
You may also tag this issue. See list of standard tags. For example, to set the confirmed and easy tags
mumi command -t +confirmed -t +easy
Or, remove the moreinfo tag and set the help tag
mumi command -t -moreinfo -t +help