[Bug dynamic-link/30127] [rfe]: enable ld audit at run-time

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

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

--- Comment #14 from Stas Sergeev <stsp at users dot sourceforge.net> ---
(In reply to Florian Weimer from comment #12)
> > But I hope the traversal of _r_debug list
> > will not became the official solution, just
> > as well as using linkmap pointers directly.
> 
> Why?  The handles are void *, so there isn't any type-checking today, and

For example getting a handle with dlopen()
can increment a refcount, making sure that
handle is not freed unexpectedly.

> > So maybe you don't need such an allocator,
> > but of course I am not aware of a use-case
> > you are referring to.
> 
> There's no lock that synchronizes the traversal of _r_debug with concurrent

Which is why I said I hope _r_debug is not
the final solution for me. :) I understand it has
multiple problems, like the one you mentioned
and more.

> dlopen/dlclose. Introducing that is difficult. Such locks are easily
> misused, and there is no precedent for exposing glibc locks in this way.

If you have a proper API for traversing, it
can use such a lock, or it can use more
advanced techniques to present the user with
the consistent list of objects that never
changes during traversal, even if someone
else does dlopen/dlclose in parallel.
Of course if its just an _r_debug and a manual
traversal, then there are much fewer options
to consider.

> I think we need to do a pass first with pointer-comparison because the names
> are not unique per namespace.

OK, as you wish, will not post a patch then,
although to me it looks like a bug-fix, not
even an extension. But it seems, after latest
"git pull" I have 32 test failures even w/o
any patches of mine, so its simpler for me
to not bother. :)
And I always had 1 test failure before the
latest "git pull" and never seen a full pass
yet (w/o any patches of mine).

> > Also what do you think about the aforementioned
> > void *dlaudit_load_module(const char *path, int flags);
> > void *dlopen_audit(const char *path, int flags, void *cookie);
> > extensions?
> 
> They seem to have poor encapsulation. If more than one module uses them, the
> auditor registered in that way might see unexpected auditing events, with
> unrecognizable cookies.

Good point!
Lets do 2 small amends then.
- void *dlaudit_load_module(const char *path, int flags);
  As above, no change.
- void *dlopen_audit(const char *path, int flags, void *audit_handle, void
*cookie2);

dlopen_audit() is changed: now the auditor handle is explicitly
passed, so this solib will only be audited by that auditor plus
all "legacy" ones (that are loaded by other means).
Also "cookie2" is not passed as a cookie to la_xxx() call-backs,
but instead put somewhere into the link_map struct. The designated
auditor will easily access that cookie2 and "legacy" auditors do
not care.
This seems to remove the problems you mentioned, doesn't it?

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