From: "Ludovic Courtès" <ludovic.courtes@inria.fr>
To: 62253@debbugs.gnu.org
Subject: bug#62253: Fakechroot execution engine doesn’t outlive ‘exec’ calls
Date: Sat, 18 Mar 2023 12:48:32 +0100 [thread overview]
Message-ID: <877cveuvov.fsf@inria.fr> (raw)
For ‘guix pack -RR’ packs, unlike the “userns” and “proot” execution
engines, the “fakechroot” execution engine doesn’t survive ‘exec’ calls:
--8<---------------cut here---------------start------------->8---
$ mkdir -p /tmp/fakechroot-test && cd /tmp/fakechroot-test/ && tar xf $(guix pack -RR openmpi intel-mpi-benchmarks bash-minimal -S /bin=bin)
$ unshare -m -U -r -f sh -c 'mount -t tmpfs none /gnu; GUIX_EXECUTION_ENGINE=fakechroot /tmp/fakechroot-test/bin/bash'
bash-5.1# echo /gnu/store/*coreutils*/bin/ls
/gnu/store/d251rfgc9nm2clzffzhgiipdvfvzkvwi-coreutils-8.32/bin/ls /gnu/store/vqdsrvs9jbn0ix2a58s99jwkh74124y5-coreutils-minimal-8.32/bin/ls
bash-5.1# test -f /gnu/store/*coreutils-8*/bin/ls
bash-5.1# echo $?
0
bash-5.1# /gnu/store/*coreutils-8*/bin/ls
bash: /gnu/store/d251rfgc9nm2clzffzhgiipdvfvzkvwi-coreutils-8.32/bin/ls: No such file or directory
--8<---------------cut here---------------end--------------->8---
This is because the ELF interpreter of the unwrapped ‘ls’ binary remains
/gnu/store/…-glibc-2.33/lib/ld-linux-x86-64-so.2 and no LD_PRELOAD
interposition can address that.
In this case, adding ‘coreutils’ to the profile (on the ‘guix pack’
command line) would give us wrapped binaries, and the problem is solved.
But in other cases, it’s not that simple. For instance, libmpi.so from
Open MPI tries to exec one its programs, using its absolute file name:
--8<---------------cut here---------------start------------->8---
$ unshare -m -U -r -f sh -c 'mount -t tmpfs none /gnu; GUIX_EXECUTION_ENGINE=fakechroot /tmp/fakechroot-test/bin/IMB-MPI1'
--------------------------------------------------------------------------
The singleton application was not able to find the executable "orted" in
your PATH or in the directory where Open MPI/OpenRTE was initially installed,
and therefore cannot continue.
For reference, we tried the following command:
/gnu/store/c7g9qalmbz4a94hwzk1v1cbq7n5m8plq-openmpi-4.1.4/bin/orted
and got the error No such file or directory.
[…]
--8<---------------cut here---------------end--------------->8---
I can think of several ways to address that:
1. Change the exec* wrappers in libfakechroot such that, on ENOENT,
they try a direct ld.so invocation to run program, like
‘run-in-namespace.c’ does.
Problem is that for this to work correctly, it would need to
compute the ‘--library-path’ argument at run time, by computing the
equivalent of (map dirname (file-needed/recursive program)).
Impractical at best.
2. Wrap/graft every package in the closure (as opposed to generating
wrappers for just those packages that appear in the profile, which
is what ‘guix pack’ currently does).
The downside is that the “userns” and “proot” execution engines
don’t need something this heavyweight: they just need a leaf
package to be wrapped.
3. Ignore the problem. After all, we’re talking about a corner case
of the “fakechroot” engine, which is a niche within a niche.
Food for thought…
Ludo’.
next reply other threads:[~2023-03-18 11:49 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-18 11:48 Ludovic Courtès [this message]
2023-03-18 21:47 ` bug#62253: Fakechroot execution engine doesn’t outlive ‘exec’ calls Josselin Poiret via Bug reports for GNU Guix
2023-03-20 9:17 ` Ludovic Courtès
2023-04-18 12:09 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=877cveuvov.fsf@inria.fr \
--to=ludovic.courtes@inria.fr \
--cc=62253@debbugs.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).