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=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 2871 invoked from network); 23 May 2020 14:12:40 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 23 May 2020 14:12:40 -0000 Received: (qmail 13569 invoked by uid 550); 23 May 2020 14:12:36 -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 13550 invoked from network); 23 May 2020 14:12:35 -0000 From: Florian Weimer To: Rich Felker Cc: Alexander Scherbatiy , musl@lists.openwall.com, Markus Wichmann References: <20200521152121.GA6521@voyager> <883535a2-1b26-183d-22f4-c3c158da2dbb@bell-sw.com> <20200522182555.GA1079@brightrain.aerifal.cx> Date: Sat, 23 May 2020 16:12:22 +0200 In-Reply-To: <20200522182555.GA1079@brightrain.aerifal.cx> (Rich Felker's message of "Fri, 22 May 2020 14:25:56 -0400") Message-ID: <87zh9y2115.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] Shared library loading * Rich Felker: >> >|/* Add a shortname only if name arg was not an explicit pathname. */ >> >|if (pathname !=3D name) p->shortname =3D strrchr(p->name, '/')+1; >>=20 >> =A0 It would be interesting to know which task this check is supposed >> to solve. > > The concept here is that non-pathname library names should be loaded > from the library path and not replaced by something (typically a > "module" or "plug-in") in a different, explicitly-loaded location that > happens to have a colliding base filename. > > For example suppose your application loads modules from $libdir/myapp/ > and has a module named "libfoo.so". Unbeknownst to you, there's also a > "libfoo.so" in the system paths, and some library you potentially load > indirectly (maybe the GPU driver for some video hardware you've never > heard of) depends on "libfoo.so". > > If dlopen("$libdir/myapp/libfoo.so") had put "libfoo.so" in the > namespace such that it would satisfy future load requests for the name > "libfoo.so", the subsequent load would break due to getting the wrong > (unrelated) library. On the other hand, that breaks FFI implementatiosn which try to guess the library name from some substring of it, and pass the absolute path (as obtained from the file system) to dlopen. (The root of the problem is that FFI users have not been taught to load libraries by their soname (e.g., libsqlite3.so.0), but expect to use strings such as "libsqlite3.so", "libsqlite3", or just "sqlite3".