[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250824022451.GJ1827@brightrain.aerifal.cx>
Date: Sat, 23 Aug 2025 22:24:51 -0400
From: Rich Felker <dalias@...c.org>
To: "Alex Xu (Hello71)" <alex_y_xu@...oo.ca>
Cc: musl@...ts.openwall.com
Subject: Re: Satisfying DT_NEEDED from previous full path dlopens
On Fri, Aug 22, 2025 at 09:23:31PM -0400, Alex Xu (Hello71) wrote:
> Hi,
>
> Previously, I posted https://www.openwall.com/lists/musl/2021/12/16/1
> about this issue. As this is still an issue, I would like to re-raise
> and summarize it.
>
> Problem: With musl, if an application calls dlopen("/app/lib1.so");
> dlopen("/app/lib2.so"), where lib2.so has DT_NEEDED: lib1.so, the second
> dlopen will fail. glibc, FreeBSD, NetBSD, OpenBSD, and possibly
> Haiku will match the dependency by DT_SONAME. Windows will match by
> filename, and macOS will match by dylib ID.
>
> Julia, OpenJDK, and Wine rely on this behavior.
>
> Solutions:
>
> 1. Julia can't use DT_RPATH or DT_RUNPATH with $ORIGIN-relative paths
> because the relative path contains the version number of lib2 which
> is not known at compile time.
>
> 2. LD_LIBRARY_PATH requires a wrapper or re-exec, but Julia may be
> embedded in another app which makes both inconvenient.
>
> 3. lib2 can be linked without lib1, but this is semantically wrong and
> causes unclear error messages if lib1 is not loaded or a wrong version
> is loaded.
>
> 4. The simplest solution is to allow DT_NEEDED to match DT_SONAME of
> previous loaded libraries, matching other libcs.
>
> Thanks,
> Alex.
We should probably revisit the idea of honoring DT_SONAME as a name to
search already-loaded libraries by. I didn't want to do this initially
because of the risk of libraries loaded via explicit path as "modules"
having name clashes with actual libraries, but it's been suggested
that they wouldn't (is this really typically the case?) have sonames,
so that might not matter.
FWIW I think there is currently a sort of hack that might work with no
changes in musl:
If you load /explicit/path/to/wrapfoo.so and this wrapfoo.so has
DT_RPATH=$ORIGIN and DT_NEEDED=foo.so, then /explicit/path/to/foo.so
will get loaded as "foo.so" and should satisfy future requests for
"foo.so". It's fairly trivial to generate such a "wrapfoo.so".
I'll put this back on the radar to look at possibly changing though.
Input on possible impacts welcome.
Rich
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.
