mbox series

[bug#41189,0/3] Add Fakechroot engine for 'guix pack -RR'

Message ID 20200511170554.22916-1-ludo@gnu.org
Headers show
Series Add Fakechroot engine for 'guix pack -RR' | expand

Message

Ludovic Courtès May 11, 2020, 5:05 p.m. UTC 
Hello Guix!

‘guix pack -RR’ is wonderful, as we know ;-), because it produces
binaries that work everywhere.

However, the overhead of PRoot is sometimes inappropriate, in
particular for those who want to run packed software on
high-performance computers, the very kind of machine that lacks
Guix and unprivileged user namespaces.

This patch series adds an optional “execution engine” to wrappers
that uses ld.so and fakechroot LD_PRELOAD trickery.  Since it’s
just LD_PRELOAD, there’s very little overhead, unlike PRoot.
On the flip side, it doesn’t work as well as PRoot, because it’s
“just” LD_PRELOAD.

For example, some of the ‘open’ calls made in libc are not
intercepted; on such call is in ‘__gconv_load_cache’, which makes
it fail, and in turn makes Guile fail to start in its first
‘scm_to_locale_string’ call.  Things that work well include Bash
and Python 3.  Let me know how well it works for your favorite
application!

The execution engine can now be chosen at run time by setting the
‘GUIX_EXECUTION_ENGINE’.

For the record, tools like udocker support a similar range of
execution engines: <https://github.com/indigo-dc/udocker/>.

Feedback welcome!

Thanks,
Ludo’.

Ludovic Courtès (3):
  pack: Wrapper honors 'GUIX_EXECUTION_ENGINE' environment variable.
  gnu: Add fakechroot.
  pack: Add relocation via ld.so and fakechroot.

 doc/guix.texi                             |  43 +++-
 gnu/packages/aux-files/run-in-namespace.c | 250 ++++++++++++++++++++--
 gnu/packages/linux.scm                    |  30 +++
 guix/scripts/pack.scm                     |  65 +++++-
 tests/guix-pack-relocatable.sh            |  23 ++
 5 files changed, 376 insertions(+), 35 deletions(-)

Comments

Carlos O'Donell May 11, 2020, 9:18 p.m. UTC | #1 
"For example, some of the ‘open’ calls made in libc are notintercepted; 
on such call is in ‘__gconv_load_cache’, which makesit fail, and in 
turn makes Guile fail to start in its first‘scm_to_locale_string’ call."
-- Ludovic Courtès wrote on Mon May 11 19:05:54+0200 2020

There are two issues at hand:
* Standard namespace issues (conformance)
* PLT avoidance issues (performance)

See:
https://sourceware.org/glibc/wiki/Style_and_Conventions#Double-underscore_names_for_public_API_functions

It is an internal implementation detail that open(2) is being called by
the library, and as such glibc bypasses the ELF interposable symbol
open, and instead calls open directly without this being visible to the
application.

There are many such cases where we bypass the ELF interposable symbol to
provide standard namespace cleanliness, performance, and so provide consistent
behaviour.

Yes, in your case this means you cannot override the behaviour of the
interface without using some kind of bind mount, or mount namespace
(to provide an alternate view of the filesystem).

We would have to argue upstream that some minimal subset of the filesystem
access should be interposable via open/close/read/write, but that's going
to get difficult quickly and have significant performance problems.

It would be simpler, IMO, to set LOCPATH and GCONV_PATH appropriately and
alter the runtime behaviour that way. If that doesn't work, perhaps because
of setuid, then we can discuss further.