search for: ld_audit

...eeding an auxiliary shared library. https://www.redhat.com/archives/libguestfs/2020-February/msg00162.html > But after spending more than an hour playing with la_objsearch() and reading 'man rtld-audit', it looks like an audit library cannot be triggered in glibc except by listing it in LD_AUDIT in the environment during exec - which is back to the same problem we have with needing LD_LIBRARY_PATH in the environment. Furthermore, although I know that glibc's audit interface is slightly different from the Solaris version it copied from, the Solaris documentation states that an audit li...

* Eric Blake: > I'm just now noticing that 'man ld' reports that you may pass '--audit > LIB' during linking to add a DT_DEPAUDIT dependency on a library > implementing the audit interface, which sounds like it might be an > alternative to LD_AUDIT for getting a library with la_objsearch() to > actually do something (but doesn't obviate the need for la_obsearch() > to be in a separate library, rather than part of the main executable, > unless a library can be reused as its own audit library...). DT_AUDIT support has yet to be im...

...> * Eric Blake: > >> I'm just now noticing that 'man ld' reports that you may pass '--audit >> LIB' during linking to add a DT_DEPAUDIT dependency on a library >> implementing the audit interface, which sounds like it might be an >> alternative to LD_AUDIT for getting a library with la_objsearch() to >> actually do something (but doesn't obviate the need for la_obsearch() >> to be in a separate library, rather than part of the main executable, >> unless a library can be reused as its own audit library...). > > DT_AUDIT su...

...nal patches to expose alternative namespaces for debugging), but there may be other nasty surprises lurking. But after spending more than an hour playing with la_objsearch() and reading 'man rtld-audit', it looks like an audit library cannot be triggered in glibc except by listing it in LD_AUDIT in the environment during exec - which is back to the same problem we have with needing LD_LIBRARY_PATH in the environment. Furthermore, although I know that glibc's audit interface is slightly different from the Solaris version it copied from, the Solaris documentation states that an audi...

On 2/14/20 1:02 PM, Eric Blake wrote: > Writing my own dlopen() wrapper directly in nbdkit seems like a > non-starter (my override has to come from a shared library before it can > replace the shared version that would be imported from -ldl, at least > for all subsequent shared library loads that want to bind to the > override). Maybe I spoke too soon. I've tried another

* 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

* 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

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

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,

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

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

...it > ourselves from libdir. However, VDDK itself requires LD_LIBRARY_PATH > to be set (because it tries to load libraries that in turn depend on a > bare library name, which no manner of dlopen() hacking can work > around, and implementing la_objsearch() is no better for requiring > LD_AUDIT to be set). And since ld.so caches the value of > LD_LIBRARY_PATH at startup (for security reasons), the ONLY way to set > it for loading vddk, while clearing it again before --run spawns a > child process, is to re-exec nbdkit with slight alterations. > > Since VDDK only runs on L...

...k libs, if we can derive it ourselves from libdir. However, VDDK itself requires LD_LIBRARY_PATH to be set (because it tries to load libraries that in turn depend on a bare library name, which no manner of dlopen() hacking can work around, and implementing la_objsearch() is no better for requiring LD_AUDIT to be set). And since ld.so caches the value of LD_LIBRARY_PATH at startup (for security reasons), the ONLY way to set it for loading vddk, while clearing it again before --run spawns a child process, is to re-exec nbdkit with slight alterations. Since VDDK only runs on Linux, we can assume the p...

...its dependencies. That may have answered our question, but not the way we wanted. :( la_objsearch() seems like it should catch these DT_NEEDED entries, but given the fact that glibc does not yet support DT_AUDIT for single-process rather than global auditing, we're stuck with having to set LD_AUDIT in the environment (which is no different than having to set LD_LIBRARY_PATH in the environment). Next idea: how hard would it be to re-exec nbdkit? Here's what I'm envisioning: nbdkit proper exposes some way to let a plugin query argv[] (necessary, so that re-exec gets the same argu...

Unfortunately this series doesn't work with the real VDDK library :-( I see: nbdkit: debug: vddk: config_complete nbdkit: debug: dlopen shim prefix set to /home/rjones/tmp/vddk-6.7.3/vmware-vix-disklib-distrib/lib64 Then a little bit later during VDDK initialization it fails with: nbdkit: debug: VixDiskLib: Could not load default plugins from

In v7: everything should work now! The re-exec code is slightly simplified, with Rich's suggestion to pass the original LD_LIBRARY_PATH rather than just the prefix being added, and I've now finished wiring up the initial dlopen() check into code that correctly computes the right prefix dir to add to LD_LIBRARY_PATH. Eric Blake (1): vddk: Add re-exec with altered environment Richard