* 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