From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.7 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2,URIBL_BLACK autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 13140 invoked from network); 29 Jul 2022 00:07:54 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 29 Jul 2022 00:07:54 -0000 Received: (qmail 32223 invoked by uid 550); 29 Jul 2022 00:07:50 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 32185 invoked from network); 29 Jul 2022 00:07:49 -0000 Date: Thu, 28 Jul 2022 20:07:36 -0400 From: Rich Felker To: Christopher Sean Morrison Cc: musl@lists.openwall.com Message-ID: <20220729000735.GN7074@brightrain.aerifal.cx> References: <43e9ad2b-d53c-5fd5-0211-766f946c90f9@landley.net> <48546934-5ccd-0b1e-bf2b-306133101c6b@landley.net> <03A11083-A7D8-409E-BA70-AC42F52FF7B2@mac.com> <20220728091827.GD1320090@port70.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] 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 wrote: > > > > * Christopher Sean Morrison [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