[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#62253: Fakechroot execution engine doesn’t outlive ‘exec’ calls
From: |
Josselin Poiret |
Subject: |
bug#62253: Fakechroot execution engine doesn’t outlive ‘exec’ calls |
Date: |
Sat, 18 Mar 2023 22:47:52 +0100 |
Hi Ludo,
Ludovic Courtès <ludovic.courtes@inria.fr> writes:
> 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…
I would like to be proven wrong, but I don't think anyone has run into
this, and there are other possible engines (that do require more
privileges, sure). It seems quite non-trivial to fix, so this can
probably go on the back-burner until someone actually complains (please
do so).
Best,
--
Josselin Poiret
signature.asc
Description: PGP signature