[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZcPVkWI0/sMV/BYJ@localhost>
Date: Wed, 7 Feb 2024 20:10:09 +0100
From: i262jq@...se
To: musl@...ts.openwall.com
Subject: Re: [PATCH 1/1] ldso: continue searching if wrong
architecture is found first
Dear Rich,
On Wed, Feb 07, 2024 at 12:30:24PM -0500, Rich Felker wrote:
> On Tue, Feb 06, 2024 at 05:22:43PM -0800, Markus Mayer wrote:
> > When LD_LIBRARY_PATH is being used, the shared library loader may end up
> > finding a shared library with the correct name but from a wrong
> > architecture. This primarily happens when a 32-bit / 64-bit mismatch
> > occurs.
> >
> > Rather than giving up immediately and aborting, the shared library
> > loader should continue to look in all known locations for a matching
> > library that may work.
>
> I don't think the concept is objectionable, but the implementation
I wonder how the loader would distinguish between "right" and "wrong"
if there are multiple libraries differing for example only in some minor
build option - which difference still can be crucial for the actual
application or for other used libraries?
In other words:
LD_LIBRARY_PATH is inherently unsafe when the applications can execute
other binaries than prepared by the same party, on a system not managed
by the same party.
Is it really worth to make LD_LIBRARY_PATH "more usable", but still unsafe?
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.
Are there any practical cases where the overhead of an extra execve()
of a small wrapper would be a noticeable problem?
> If you think there are less invasive ways to do this, I'd be happy to
> hear other ideas too.
The least invasive way might be to avoid introducing such support?
My perspective reflects years of handling third party applications and the
consequences of their use of LD_LIBRARY_PATH. This works - *mostly*.
At the same time, building and freely mixing applications linked
to a plethora of simultaneously available versions and instances of
libraries, this worked without any problems ever, thanks to the loader
with --library-path. AFAICS, reliance on checks in the loader would
never provide the same level of robustness, ease and flexibility.
Thanks for musl, 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.
