From: i262jq@0w.se
To: musl@lists.openwall.com
Subject: Re: [musl] [PATCH 1/1] ldso: continue searching if wrong architecture is found first
Date: Thu, 8 Feb 2024 16:52:53 +0100 [thread overview]
Message-ID: <ZcT41aOV1My6DH1Y@localhost> (raw)
In-Reply-To: <Pine.BSM.4.64L.2402071946230.13700@herc.mirbsd.org>
On Wed, Feb 07, 2024 at 07:51:54PM +0000, Thorsten Glaser wrote:
> i262jq@0w.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
next prev parent reply other threads:[~2024-02-08 15:53 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-07 1:22 [musl] [PATCH 0/1] ldso: continue searching if wrong architecture is found Markus Mayer
2024-02-07 1:22 ` [musl] [PATCH 1/1] ldso: continue searching if wrong architecture is found first Markus Mayer
2024-02-07 17:30 ` Rich Felker
2024-02-07 19:10 ` i262jq
2024-02-07 19:51 ` Thorsten Glaser
2024-02-08 15:52 ` i262jq [this message]
2024-02-07 20:59 ` Markus Mayer
2024-02-07 8:26 ` [musl] [PATCH 0/1] ldso: continue searching if wrong architecture is found i262jq
2024-02-07 16:45 ` enh
2024-02-07 17:07 ` Thorsten Glaser
2024-02-07 17:54 ` enh
2024-02-07 18:09 ` Colin Cross
2024-04-02 20:59 ` Markus Mayer
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZcT41aOV1My6DH1Y@localhost \
--to=i262jq@0w.se \
--cc=musl@lists.openwall.com \
/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.vuxu.org/mirror/musl/
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 NNTP newsgroup(s).