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 13784 invoked from network); 23 May 2020 16:06:07 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 23 May 2020 16:06:07 -0000 Received: (qmail 7263 invoked by uid 550); 23 May 2020 16:06:04 -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 7241 invoked from network); 23 May 2020 16:06:03 -0000 Date: Sat, 23 May 2020 12:05:51 -0400 From: Rich Felker To: Florian Weimer Cc: Alexander Scherbatiy , musl@lists.openwall.com, Markus Wichmann Message-ID: <20200523160551.GH1079@brightrain.aerifal.cx> References: <20200521152121.GA6521@voyager> <883535a2-1b26-183d-22f4-c3c158da2dbb@bell-sw.com> <20200522182555.GA1079@brightrain.aerifal.cx> <87zh9y2115.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87zh9y2115.fsf@mid.deneb.enyo.de> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Shared library loading On Sat, May 23, 2020 at 04:12:22PM +0200, Florian Weimer wrote: > * Rich Felker: > > >> >|/* Add a shortname only if name arg was not an explicit pathname. */ > >> >|if (pathname != name) p->shortname = strrchr(p->name, '/')+1; > >> > >>   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". I'm not sure what breakage you're thinking about. As long as the the name resolves to the same file (dev/ino pair) as one already loaded, the already-loaded one will be used. So it doesn't matter if you load "libfoo.so.0" or "libfoo.so" as long as they're both links to the same underlying file. The above-described distinction only happens when there are actually different files, one in an absolute or relative path provided by the caller (any string containing a '/'), and another requested by dlopen or DT_NEEDED for search (no '/'). But yes Python is doing some really broken stuff in this area and should be fixed. Rich