mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Florian Weimer <fw@deneb.enyo.de>
To: Rich Felker <dalias@libc.org>
Cc: Alexander Scherbatiy <alexander.scherbatiy@bell-sw.com>,
	 musl@lists.openwall.com,  Markus Wichmann <nullplan@gmx.net>
Subject: Re: [musl] Shared library loading
Date: Sat, 23 May 2020 16:12:22 +0200	[thread overview]
Message-ID: <87zh9y2115.fsf@mid.deneb.enyo.de> (raw)
In-Reply-To: <20200522182555.GA1079@brightrain.aerifal.cx> (Rich Felker's message of "Fri, 22 May 2020 14:25:56 -0400")

* 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".

  reply	other threads:[~2020-05-23 14:12 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-21 11:27 Alexander Scherbatiy
2020-05-21 15:21 ` Markus Wichmann
2020-05-22 18:07   ` Alexander Scherbatiy
2020-05-22 18:25     ` Rich Felker
2020-05-23 14:12       ` Florian Weimer [this message]
2020-05-23 16:05         ` Rich Felker
2020-05-25 17:26       ` Alexander Scherbatiy
2020-05-25 17:46         ` Rich Felker
2020-05-27 18:10           ` Dmitry Samersoff
2020-05-28 18:53             ` Szabolcs Nagy
2020-05-28 19:20             ` Jeffrey Walton
2020-05-28 19:29               ` Rich Felker
2020-06-04 19:37           ` Alexander Scherbatiy
2020-06-04 19:48             ` Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87zh9y2115.fsf@mid.deneb.enyo.de \
    --to=fw@deneb.enyo.de \
    --cc=alexander.scherbatiy@bell-sw.com \
    --cc=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    --cc=nullplan@gmx.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).