Libguestfs - Feb 2020 - Re: alternatives for hooking dlopen() without LD_LIBRARY_PATH or LD_AUDIT?

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?

We don't distribute the proprietary library, end users have to choose
to accept the terms of the (very poisonous) license on that library
and so they download and install it themselves and just give us a path
where they installed it.

With all this low quality proprietary software involved I don't expect
there's going to be a clean way to solve this, was really only
wondering if there's a better way than re-execing the whole program.
But we do at least have the re-exec working now.
> 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.
Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v

* 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

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, 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?
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 Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW