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

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

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.

Thanks for pointing me to the right path.

Regards,
--
Daniel Villeneuve