[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZcT41aOV1My6DH1Y@localhost>
Date: Thu, 8 Feb 2024 16:52:53 +0100
From: i262jq@...se
To: musl@...ts.openwall.com
Subject: Re: [PATCH 1/1] ldso: continue searching if wrong
architecture is found first
On Wed, Feb 07, 2024 at 07:51:54PM +0000, Thorsten Glaser wrote:
> i262jq@...se dixit:
> >To the contrary, relying on the explicit loader in a wrapper is totally
> >safe, because the path to the libraries is not inherited at any later
> >exec.
>
> What if the first binary you run is not the one that needs to get the
> changed library path, but the binaries it runs?
Only starters/wrappers shall be in the PATH or otherwise run. Not any
application executables directly.
Every wrapper sets the right library path for its binary.
> >Are there any practical cases where the overhead of an extra execve()
> >of a small wrapper would be a noticeable problem?
>
> It may be very hard to get these into the right places.
Why hard? You do not package software without knowing what are its
executables. To replace them with wrappers is a trivial task, or rather
to put the wrappers separately, in another file tree or a directory to
be used via PATH or directly.
If the software is to be used from locally varying paths, you may choose
to generate wrappers at "installation"/"file-tree-relocation" stage
or otherwise just let your pre-made wrappers examine a _package_specific_
environment variable - resulting in all the semantics of LD_LIBRARY_PATH,
but in a totally safe fashion.
In other words, I do not see this as a task for the loader (who generally
does *not* have all the relevant information, only the limited data
from elf), but as a task for the packaging, with an available solution
of low cost and complete reliability.
Regards,
/i262jq
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
