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

[Daniel Villeneuve <dvilleneuve.4142@gmail.com>]

On 11/23/20 5:39 AM, Florian Weimer wrote:
> * 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 for the warning.
I understand I was inferring correctness from implementation-defined behavior (vs published spec).

Is there a doc on the stable part of dynamic-loading rules regarding a filesystem library name, its  internal soname and already loaded shared libraries?
In my case, something about when the argument to dlopen could/will be reused internally without being loaded vs must be loaded anew.
I could not find this information except by reading the source code and asking on the list.

Regards,
--
Daniel Villeneuve