[Libguestfs] alternatives for hooking dlopen() without LD_LIBRARY_PATH or LD_AUDIT?

[Eric Blake]

On 2/21/20 11:42 AM, Richard W.M. Jones wrote:

>>> To be clear, the situation is:
>>>
>>>    nbdkit (free)
>>>     -> dlopens nbdkit-vddk-plugin.so (free)
>>>       -> dlopens libvixDiskLib.so (proprietary)
>>>         -> dlopens other proprietary plugins
>>>         -> both libvixDiskLib.so and its plugins have DT_NEEDED
>>>            "libstdc++.so.X" and other objects that have odd/old
>>>            compiled versions in its own directory
>>>
>>> It's the proprietary library libvixDiskLib.so (colloquially known as "VDDK")
>>> which has trouble opening its own plugins.  I guess you mean adding
>>> DT_* to the proprietary library?
>>
>> No, to nbdkit-vddk-plugin.so.
>>
>> But it looks like have misunderstood the request.
>>
>> Do you want to inhibit loading the libstdc++.so.X from vddk, or the
>> opposite—ensure that it is loaded?  The latter obviously taints the
>> process.  But maybe that's what you want?
> 
> Ideally load it but only make it available to VDDK.  I think Eric was
> working on something along these lines, using dlmopen.

The nbdkit process having its namespace tainted by VDDK code is (so far) 
a non-issue, as long as the libraries that VDDK ships that override 
system libraries do not intersect with the set of libraries used by 
nbdkit itself.  (For example, VDDK overrides libstdc++.so, but since 
nbdkit is written in C rather than C++, we don't care what C++ stuff 
VDDK drags into the process).  But you are right that if, down the road, 
a future VDDK release poisons even more system libraries, we'd NEED to 
use dlmopen() to isolate the real system library interfaces used by 
nbdkit from the out-of-date override library interfaces pulled in by 
VDDK's DT_NEEDED.

However, it was my annoying discovery that dlmopen() is still not a 
first-class citizen in glibc/gdb that spawned this whole thread in the 
first place.  While I did have a working example using dlmopen() where I 
was able to hook dlopen() to my heart's content, that hook was not alone 
sufficient to overcome the DT_NEEDED problems, and it made life a lot 
tougher since anything in the dlmopen'd space was undebuggable under gdb.

Loading the leaf dependencies first before libvixDiskLib.so has no 
difference on the amount of tainting to the overall nbdkit process 
compared to letting the leaf dependencies get pulled in via 
LD_LIBRARY_PATH under re-exec.

> 
> We're sort of lucky that none of the libraries that VDDK tries to load
> overlaps with libraries that nbdkit uses (currently).
> 
> Rich.
> 

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org