On 2/13/20 10:04 AM, Richard W.M. Jones wrote:
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 system libraries (libcrypto.so.X etc) and
it cannot find those because $LD_LIBRARY_PATH is not set.
Setting $LD_LIBRARY_PATH using setenv around the call to InitEx() does
not work because glibc only consults $LD_LIBRARY_PATH when the program
starts up. Various workarounds have been suggested for this but none
of them are pleasant
(https://stackoverflow.com/questions/6713692/problems-with-using-setenv-and-then-making-the-dlopen-call).
So currently we must have nbdkit start up with $LD_LIBRARY_PATH set,
in other words how it works at the moment.
Here's my rough [untested] idea, after reading
https://hackerboss.com/overriding-system-functions-for-fun-and-profit/.
Create a shim shared library that implements only one function - a
replacement dlopen(), something like:
#define _GNU_SOURCE
#include <dlfcn.h>
void *(*orig_dlopen)(const char *filename, int flags);
/* NULL for normal behavior, or set when we want to override
* relative dlopen()s to instead be an absolute open with prefix.
*/
char *override_dir;
void *dlopen(const char *filename, int flags)
{
if (override_dir && !strchr(filename, '/'))
... code to rewrite filename into override_dir/filename
return orig_dlopen (filename, flags);
}
void
_init(void)
{
orig_dlopen = dlsym(RTLD_NEXT, "dlopen");
}
then in our vddk plugin, we dlmopen(LM_ID_NEWLM, "shim", flags) to
create a new namespace, dlinfo() to learn the id of that namespace, then
override_dir = libdir; dlmopen(id, "vddk", flags) so that vddk gets
loaded into that same namespace but where all of its relative loads get
rewritten into absolute loads.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
_______________________________________________
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs
