[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200522182555.GA1079@brightrain.aerifal.cx>
Date: Fri, 22 May 2020 14:25:56 -0400
From: Rich Felker <dalias@...c.org>
To: Alexander Scherbatiy <alexander.scherbatiy@...l-sw.com>
Cc: musl@...ts.openwall.com, Markus Wichmann <nullplan@....net>
Subject: Re: Shared library loading
On Fri, May 22, 2020 at 09:07:20PM +0300, Alexander Scherbatiy wrote:
> On 21.05.2020 18:21, Markus Wichmann wrote:
>
> >On Thu, May 21, 2020 at 02:27:24PM +0300, Alexander Scherbatiy wrote:
> >>Hello,
> >>
> >>I use Alpine Linux 3.11.6 with musl libc (x86_64) version 1.1.24.
> >>
> >>I have two shared libraries "a" and "b" each of which is placed in its own
> >>directory and lib "b" depends on "a".
> >>First, I use dlopen to load lib "a" with "RTLD_NOW | RTLD_GLOBAL" flags.
> >>Second, I load lib "b" with flag "RTLD_LAZY".
> >>
> >>The "b" library loading works on my Ubuntu 19.10 and fails on Alpine 3.11.6
> >>with message:
> >> dlopen failed: Error loading shared library liba.so: No such file or
> >>directory (needed by /root/load-lib-sample/bin/b/libb.so)
> >>Should it work on Alpine with musl libc as well?
> >[...]
> >
> >I shall leave the "Should it work" to others who know more about this
> >than me. But I will tackle the "Why doesn't it work". It appears however
> >the behavior is intentional (whether the consequences are as well
> >remains to be seen). Namely in line 1140f. of dynlink.c (revision
> >72658c65):
> >
> >
> >|/* 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.
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.
