similar to: alternatives for hooking dlopen() without LD_LIBRARY_PATH or LD_AUDIT?

On 2/14/20 3:29 PM, Eric Blake wrote: > On 2/14/20 1:02 PM, Eric Blake wrote: > >> Writing my own dlopen() wrapper directly in nbdkit seems like a >> non-starter (my override has to come from a shared library before it >> can replace the shared version that would be imported from -ldl, at >> least for all subsequent shared library loads that want to bind to the

On Fri, Feb 21, 2020 at 05:02:12PM +0100, Florian Weimer wrote: > * 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,

On 2/14/20 1:02 PM, Eric Blake wrote: > Writing my own dlopen() wrapper directly in nbdkit seems like a > non-starter (my override has to come from a shared library before it can > replace the shared version that would be imported from -ldl, at least > for all subsequent shared library loads that want to bind to the > override). Maybe I spoke too soon. I've tried another

* Eric Blake: > So with that said, here's a question I just thought of: > > If your patch for glibc support for DT_AUDIT is incorporated, is it > possible to mark a shared library as its own audit library via > DT_AUDIT? That is, if nbdkit-vddk-plugin.so can provide entry points > for _both_ the nbdkit interface (which satisfies dlopen() from the > nbdkit binary) and

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

On 2/17/20 9:12 AM, Florian Weimer wrote: > * Eric Blake: > >> I'm just now noticing that 'man ld' reports that you may pass '--audit >> LIB' during linking to add a DT_DEPAUDIT dependency on a library >> implementing the audit interface, which sounds like it might be an >> alternative to LD_AUDIT for getting a library with la_objsearch() to

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

* 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

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

* Eric Blake: > I'm just now noticing that 'man ld' reports that you may pass '--audit > LIB' during linking to add a DT_DEPAUDIT dependency on a library > implementing the audit interface, which sounds like it might be an > alternative to LD_AUDIT for getting a library with la_objsearch() to > actually do something (but doesn't obviate the need for

--- configure.ac | 5 +++++ plugins/vddk/vddk.c | 4 ++++ 2 files changed, 9 insertions(+) diff --git a/configure.ac b/configure.ac index d71f06e4..57626a76 100644 --- a/configure.ac +++ b/configure.ac @@ -321,6 +321,11 @@ AC_SEARCH_LIBS([dlsym], [dl dld], [ ]) LIBS="$old_LIBS" +old_LIBS="$LIBS" +LIBS="$LIBS -ldl" +AC_CHECK_FUNCS([dlmopen])

From: "Richard W.M. Jones" <rjones@redhat.com> Do not use LD_LIBRARY_PATH to locate the VDDK library. Setting this always causes problems because VDDK comes bundled with broken replacements for system libraries, such as libcrypto.so and libstdc++.so. Two problems this causes which we have seen in the real world: (1) User does ‘export LD_LIBRARY_PATH=vmware-vix-disklib-distrib’

Unfortunately this series doesn't work with the real VDDK library :-( I see: nbdkit: debug: vddk: config_complete nbdkit: debug: dlopen shim prefix set to /home/rjones/tmp/vddk-6.7.3/vmware-vix-disklib-distrib/lib64 Then a little bit later during VDDK initialization it fails with: nbdkit: debug: VixDiskLib: Could not load default plugins from

In the next patch, we want to get rid of the requirement for the user to supply LD_LIBRARY_PATH pointing to vddk libs, if we can derive it ourselves from libdir. However, VDDK itself requires LD_LIBRARY_PATH to be set (because it tries to load libraries that in turn depend on a bare library name, which no manner of dlopen() hacking can work around, and implementing la_objsearch() is no better for

I'm a lot happier with this version: no mucking with dlmopen(). It does add a bit more coupling between nbdkit proper and the vddk plugin (namely, nbdkit now exports a new function that the vddk plugin relies on), but patch 2 adds testsuite coverage of the new function so we shouldn't regress. Patch 1 and 2 are new, patch 3 is unchanged from when Rich posted it in v2, and patch 4 is

I couldn't get this to work in the end. This is the latest non-working version. This email documents what doesn't work for the permanent record. The central problem is that VDDK InitEx() appears to dlopen() various of its own plugins. Although I wasn't able to capture exactly what dlopen() command it is running, the plugins cannot be loaded because they rely on the recompiled

On Mon, Feb 17, 2020 at 09:34:12PM -0600, Eric Blake wrote: > In the next patch, we want to get rid of the requirement for the user > to supply LD_LIBRARY_PATH pointing to vddk libs, if we can derive it > ourselves from libdir. However, VDDK itself requires LD_LIBRARY_PATH > to be set (because it tries to load libraries that in turn depend on a > bare library name, which no manner

On 2/17/20 12:17 PM, Richard W.M. Jones wrote: > Unfortunately this series doesn't work with the real VDDK library :-( > > I see: > > nbdkit: debug: vddk: config_complete > nbdkit: debug: dlopen shim prefix set to /home/rjones/tmp/vddk-6.7.3/vmware-vix-disklib-distrib/lib64 > > Then a little bit later during VDDK initialization it fails with: > >

In v7: everything should work now! The re-exec code is slightly simplified, with Rich's suggestion to pass the original LD_LIBRARY_PATH rather than just the prefix being added, and I've now finished wiring up the initial dlopen() check into code that correctly computes the right prefix dir to add to LD_LIBRARY_PATH. Eric Blake (1): vddk: Add re-exec with altered environment Richard

Differences from v4: Patch 1 is simplified: I realized that since we already use -rdynamic for nbdkit (after all, we WANT our dlopen()d plugins to be able to call our nbdkit_* exports), it is only a matter of adding dlopen to the set of symbols that we export. With that done, there is no separate shared library needed; our dlopen shim is now part of nbdkit proper, and we don't have to tweak