Re: [Libguestfs] alternatives for hooking dlopen() without LD_LIBRARY_PATH or LD_AUDIT?
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