[Bug dynamic-link/30134] DT_AUDIT is ignored for dlopen()ed solib

["stsp at users dot sourceforge.net" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=30134

--- Comment #5 from Stas Sergeev <stsp at users dot sourceforge.net> ---
(In reply to Florian Weimer from comment #4)
> Maybe in theory, but it's not how the current implementation is structured.
> It depends on an auditing flag in RELRO memory for hardening, so that the
> auditing (function) pointers cannot be overwritten if the process did not
> start with auditing enabled.

Yes, I already "noticed" that.
That's why my dlload_audit_module()
patch is still not posted. :(
But it will be posted sooner or later.
Yes, I realize it may be rejected
because it moves the audit list to
rw space, but what should I do if I
need that patch...
Do you have any suggestion in that
area while I am still polishing it?


> We would also have to figure out all the small corner cases and work out
> what to do for them. For example, auditing is currently a process-global
> operation, and the auditing modules are never unloaded after being created.
> Adding dlopen support might change that: auditing could perhaps be
> restricted to the local search scope, and dlclose might unload the auditor
> as well. Or not, it's hard to tell without some exploration.

Yes, closing the module that had
DT_AUDIT looks like a good place
to unload the audit module as well,
unless some other solib also had
the same DT_AUDIT. So perhaps that
would need a refcount.


> We also have hard limits on the number of auditors. The explicit one
> (namespace count) is perhaps somewhat easy to overcome, but there is also
> the static TLS space consumption by new auditing namespaces.

I am yet to understand why every
audit module needs a new NS. Wouldn't
it be possible to use one separate
NS for all audit modules?

-- 
You are receiving this mail because:
You are on the CC list for the bug.