search for: la_objsearch

...'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 implemented in glibc...

...ng to see if I can further reduce things (maybe with -rdynamic) so that the main binary itself provides the dlopen() override without needing 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...

.../archives/libguestfs/2020-February/msg00154.html https://bugzilla.redhat.com/show_bug.cgi?id=1756307#c7 https://sourceware.org/bugzilla/show_bug.cgi?id=15971#c5 However, when Florian saw it, he suggested that my solution of dlmopen() for a shim library that overrides dlopen() is reinventing what la_objsearch() can already do. This is in part because the moment you dlmopen() a library into a separate namespace, you can't debug it (both glibc and gdb need additional patches to expose alternative namespaces for debugging), but there may be other nasty surprises lurking. But after spending more th...

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

...ake: > 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 implemented in glibc: <https://sourc...

...Y_PATH pointing to vddk 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 altera...

...to supply LD_LIBRARY_PATH pointing to vddk 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 o...

...-linux-x86-64.so.2] > > which I suppose doesn't actually go through dlopen ... And we were wondering if the dlopen() with an absolute file name would help the dynamic linker alter its search path for 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 envir...

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