search for: dlmopen

...anged, 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]) +LIBS="$old_LIBS" + dnl Test if <iconv.h> header can build working binaries. dnl dnl On FreeBSD: iconv and libiconv both exist, both can be installed diff --git a/plugins/vddk/vddk.c b/plugins/vddk/vddk.c index c49eebcd..b988946b 100644 --- a/plugins/vddk/vddk.c +++ b/plugins/v...

...nt 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. We're sort of lucky that none of the libraries that VDDK tries to load overlaps with libraries that nbdkit uses (currently). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora...

...b.so, but where that hook code can still defer back to the real dlopen() from -ldl and does not penalize child processes. I managed to create a solution that avoids the need to set LD_PRELOAD_PATH at all by installing a shared library that hooks dlopen(), then loading both my shim and vddk via dlmopen() without the use of RTLD_GLOBAL or RTLD_DEEPBIND. More links on my solution: https://www.redhat.com/archives/libguestfs/2020-February/msg00154.html https://bugzilla.redhat.com/show_bug.cgi?id=1756307#c7 https://sourceware.org/bugzilla/show_bug.cgi?id=15971#c5 However, when Florian saw it, he s...

...ches the directory we supplied explicitly. However, we can't call setenv() to change LD_LIBRARY_PATH dynamically, since (for security reasons) ld.so uses only a value of the environment variable cached prior to main(). Instead, we can fix the problem by relying on the fact that Linux provides dlmopen(), which opens a shared library in a new namespace. We first load a shim library into this namespace which overrides the dlopen() present in the main executable, then load the VDDK library. All further dlopen() calls made during VDDK initialization now go through our shim, at which point we can rew...

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

...vddk-plugin.so that gets loaded later, the first bound dlopen() in use for all subsequent loads is from my shim. It's still a bit less clean than I'd like (it requires tighter coupling between nbdkit and nbdkit-vddk-plugin.so than what used to exist), but the fact that it works without dlmopen() or LD_LIBRARY_PATH is in its favor. I'm now polishing up the experiment, and will post the patch when it's ready. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org

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

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

...gets loaded later, the first bound dlopen() > in use for all subsequent loads is from my shim.  It's still a bit less > clean than I'd like (it requires tighter coupling between nbdkit and > nbdkit-vddk-plugin.so than what used to exist), but the fact that it > works without dlmopen() or LD_LIBRARY_PATH is in its favor.  I'm now > polishing up the experiment, and will post the patch when it's ready. Progress report: I've posted a v4 series that relies on a shared library in the main executable; but I'm still trying to see if I can further reduce things (...

...LD_LIBRARY_PATH is too strong (that would leak into the child process created by --run, and makes the user think about issues that we'd rather cover automatically). But overriding dlopen() to make it easier to prepend a directory name under our control requires either a separate namespace via dlmopen() (which itself is annoying - it messes up gdb debugging), or that the override occur prior to any other library that also depends on -ldl. Which means that if we are going to provide this functionality, we have to do so from nbdkit proper. Note that properly injecting a dlopen shim for all subse...

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