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