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

[Florian Weimer]

* Richard W. M. Jones:

> On Fri, Feb 21, 2020 at 04:00:30PM +0100, Florian Weimer wrote:
>> * Richard W. M. Jones:
>> 
>> > On Fri, Feb 21, 2020 at 01:19:34PM +0100, Florian Weimer wrote:
>> >> I think what confuses me is that keep talking about a single binary, but
>> >> clearly there is this separate vddk DSO, and there is talk of plugins.
>> >> So it seems to me that multiple files are involved already?
>> >
>> > nbdkit is a standalone binary that happens to be able to load plugins
>> > from a well-known path, eg nbdkit-vddk-plugin.so.  nbdkit knows the
>> > path for plugins, and there's a wrapper allowing it to get local
>> > plugins even when it's still in the build directory.  Adding another
>> > file would mean another path (or overloading the meaning of the plugin
>> > path) and just makes the whole thing more fragile and complex.
>> >
>> > Having said all that, what would also solve this is either an API for
>> > updating LD_LIBRARY_PATH after the program has started; or making
>> > setenv ("LD_LIBRARY_PATH",...) DTRT*; or some kind of dlopen() variant
>> > which takes a library path as an extra parameter.
>> 
>> Have you tried adding DT_RUNPATH or DT_RPATH to nbdkit-vddk-plugin.so?
>> Or does the path have to be chosen dynamically?
>
> 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?

Thanks,
Florian