mailing list of musl libc
 help / color / mirror / code / Atom feed
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

  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).