[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87zh9y2115.fsf@mid.deneb.enyo.de>
Date: Sat, 23 May 2020 16:12:22 +0200
From: Florian Weimer <fw@...eb.enyo.de>
To: Rich Felker <dalias@...c.org>
Cc: Alexander Scherbatiy <alexander.scherbatiy@...l-sw.com>, musl@...ts.openwall.com, Markus Wichmann <nullplan@....net>
Subject: Re: Shared library loading
* 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".
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.
