Date: Sat, 23 May 2020 12:05:51 -0400 From: Rich Felker <dalias@...c.org> To: Florian Weimer <fw@...eb.enyo.de> Cc: Alexander Scherbatiy <alexander.scherbatiy@...l-sw.com>, musl@...ts.openwall.com, Markus Wichmann <nullplan@....net> Subject: Re: 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
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.