Re: what is the dlopen criterion used to decide if library needs to be loaded?

[Florian Weimer <fweimer@redhat.com>]

* Daniel Villeneuve:

> On 11/13/20 5:18 PM, Daniel Villeneuve wrote:
>> On 11/13/20 4:41 PM, Florian Weimer wrote:
>>>> In the end, I've rebuilt the library using the same name (not being
>>>> sure whether the inode would be the same or not), and before dlopen, I
>>>> create a hard link with a new unique name on the library and use that
>>>> as arg to dlopen (and then delete the hard link).
>>>>
>>>> Is this a safe way to ensure a newly built library is really loaded?
>>> It depends on what the soname of the library is.  If you set it to a
>>> fixed value, the new library may be opened, but not loaded eventually
>>> because the soname is already known to the system.
>>
>> This internal test about soname (dlopen skipping loading a library)
>> is new to me.  So loading two different library files, with different
>> names, could end up in skipping the second load because of same
>> soname?  My tests show that even with the same soname, dlopen/dlsym
>> use the new library (loaded with the unique name).
>>
>> My understanding of ld -hSONAME is for registering at link-time in an
>> executable which arg to use for an eventual dlopen.  Not sure about
>> the connection with calling dlopen on a specific path...
>
> I extended my search in glibc source from dlfcn to elf, and found in
> elf/dl-load.c (_dl_map_object) the part that compares the name passed
> to dlopen and previously registered sonames.
>
> Based on that, I could trigger the problem you allude to above, by
> using a specially crafted soname for "ld -hSONAME" that ends up
> matching a unique name I will generate in the future: in this case,
> the library with this specific unique name is not loaded.
>
> This explains my successful tests as well, since the unique names
> passed to dlopen are different from any soname used before, so the
> test in _dl_map_object necessarily fails.

There are some suggestions that we should not load an object if its
soname matches one already known to the system.

Unfortunately I can't find the patch reference right now.  If we make
this change in glibc, I believe your application would behave
differently.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill