Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 8 Feb 2024 16:52:53 +0100
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:
> 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.


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.