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

Florian Weimer fweimer at redhat.com
Fri Feb 21 15:00:30 UTC 2020


* 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?

If you merely want to prevent loading of libstdc++.so or libcrypto.so by
vddk, it may be possible to explicitly dlopen DSOs of that name before
loading vddk.  But there is an existing bug where we do not duplicate
properly on soname alone, so we may have to fix that first.

Thanks,
Florian




More information about the Libguestfs mailing list