[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220729000735.GN7074@brightrain.aerifal.cx>
Date: Thu, 28 Jul 2022 20:07:36 -0400
From: Rich Felker <dalias@...c.org>
To: Christopher Sean Morrison <brlcad@....com>
Cc: musl@...ts.openwall.com
Subject: Re: dynamic linker is capturing "reserved" library names
erroneously
On Thu, Jul 28, 2022 at 04:39:07PM -0400, Christopher Sean Morrison wrote:
>
> > On Jul 28, 2022, at 5:18 AM, Szabolcs Nagy <nsz@...t70.net> wrote:
> >
> > * Christopher Sean Morrison <brlcad@....com> [2022-07-27 19:06:24 -0400]:
> >> First consideration, the code seems to take a position that those
> >> library names are somehow universally reserved and I believe that
> >> to be incorrect.
As others have noted, the behavior of -lrt is defined as linking the
standard library for realtime interfaces, not a user-defined library
by that name. The specification goes so far as to say, regarding use
of -L to try to override that:
If a directory specified by a -L option contains files with names
starting with any of the strings "libc.", "libl.", "libpthread.",
"libm.", "librt.", "libtrace.", "libxnet.", or "liby.", the results
are unspecified.
You may think it seems like it should be okay to use the name "librt"
if you're not linking the standard -lrt, but imagine what would happen
if you were on an implementation where some of the standard functions
were defined in a discrete librt.so rather than all integrated in
libc.so like musl does: any *other* library that got pulled in
(possibly even one of the standard ones) that depends on librt would
end up getting that DT_NEEDED reference resolved to your library by
the same name, rather than to the standard one, and you would end up
with runtime link errors resolving the missing symbols.
I'm really surprised you haven't run into any problems with this clash
before. Surely I'd think someone would have tried to use clock_gettime
(the only modern way to get the current system clock time) in a
program that also needs to use your library, and on many historical
implementations, including glibc up until recently, you couldn't get
clock_gettime without -lrt (this the horrible syscall() hacks all over
the place to use the syscall directly).
> > i believe the reason musl has to special case the names in ld.so
>
> > is to be able to load libraries linked against glibc. another
> > reason is to support looking up symbols in librt etc via dlsym.
>
> That is why I proposed a solution of deferring the capture until
> after searching, so it will both satisfy that desire to resolve
> symbols for when -lm, -lr, -lpthread, etc are specified while also
> supporting the general case where such libraries actually do exist
> and are intended to be used.
This would cause very bad things to happen if someone copied the glibc
versions of those libraries around with a glibc-linked program they
were trying to use with ABI-compat, not aware that they were actually
part of glibc and not third-party libraries the application needed.
There is something of a long-term direction to decouple the ABI-compat
stuff from musl, and I'm not sure if it would make sense to unreserve
the names at the same time. A proposal to do this, like any proposal
for supporting nonstandard functionality that could have unforseen
consequences, would need to involve research into what those
consequences might be, if any. It might end up being okay to do
something like first hardening protection against loading glibc-linked
libraries by those names (assuming they're the corresponding parts of
the standard library from glibc) and then doing like you said, only
using them as fallbacks after search.
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.
