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

[Florian Weimer <fweimer at redhat dot com>]

* 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 la_version/la_objsearch() (which satisfy the
> requirements for use from the audit code in ld.so), _and_ during the
> compilation of nbdkit-vddk-plugin.so, we marked the library as its own
> DT_AUDIT entry, would the mere act of dlopen("nbdkit-vddk-plugin.so")
> from nbdkit be sufficient to trigger audit actions such as
> la_objsearch() on all subsequent shared loads (whether by dlopen() or
> DT_NEEDED) performed by nbdkit-vddk-plugin.so and its descendant
> loaded libraries?

So you want to dlopen nbdkit-vddk-plugin.so and launch a new auditor
even if the process so far hasn't used auditing?  And the main program
(which links agains a library which eventually makes this dlopen call)
would not know anything about the existence of this specific plugin and
auditing?

This isn't currently supported.  It's not just that the glibc
implementation cannot do it.  The audit API (as sketched in <link.h>) is
not a good fit for late loading where you have never observed open
events.  It pretty much assumes that auditors are loaded magically
*before* program start, so that they can observe all open calls and set
up their own data structures along the way.

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?

Thanks,
Florian