Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 7 Feb 2024 09:26:31 +0100
Subject: Re: [PATCH 0/1] ldso: continue searching if wrong
 architecture is found

On Tue, Feb 06, 2024 at 05:22:42PM -0800, Markus Mayer wrote:
> script of the app will set LD_LIBRARY_PATH to the directory containing
> What we have discovered is that 64-bit applications launched by the
> 32-bit app will fail due to a shared library mismatch. The 32-bit app

This is a known problem with the LD_LIBRARY_PATH semantics.

> The solution:
> The shared library loader needs to keep searching the rest of the
> library search path if the library it found in LD_LIBRARY_PATH could not
> be mapped. If the library loader does this, everything will work fine as
> long as the library resides on the system in a well known path.

This would possibly solve your particular case, but not the main trouble
inherent in LD_LIBRARY_PATH (a child process mapping an unexpected
library instance).

A well working solution is to wrap each application binary in a starter
which explicitly runs the dynamic loader with the argument
 --library-path <where the libraries are>
(then the path to the application binary and the arguments, of course)

This solves the problems reliably and is well proven.

My 2c

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.