[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 #44 from Stas Sergeev <stsp at users dot sourceforge.net> ---
(In reply to Jonathon Anderson from comment #42)
> After all, all solibs are perfectly functional regardless of whether you
> load it via LD_PRELOAD or dlopen or DT_NEEDED. Shouldn't auditors follow the
> same principle?

Normally yes, but when you bring up
things like "but it should run before
any ctors", then these must be evaluated
case-by-case.


> > Is that picture remotely correct? I guess no, as
> > it is based on too many assumptions from me. :)
> It's in the right direction. The only reason I bring up my use case is as an
> example auditor that would be broken by this dynamic loading feature in its
> current state.

This is a very harsh statement.
Nothing will be broken. At worst, you won't
be able to use that dynamic loading for your
case. Given that you have only 1 auditor, no
intention to change the app and a requirement
for an auditor to run before any ctors, I think
this "worst case" is already unavoidable. :)


> The parallelism issue is present here too. There's no association between an
> la_objsearch and the resulting la_objopen,

I think you can associate by "name".
The name in objsearch and abjopen should
match I think. But I've heard your other
arguments against objsearch, yes.


> Indeed. My primary goal is to ensure the proposed "tools" for your use case
> don't unwittingly destroy my use case in the process. :)

I don't even see why this can be the case.
If it is, why aren't we discussing _that_,
instead of everything else? :)


> If the interface is defined such that no other la_objopen calls from threads
> running in parallel can trigger before that first la_activity(CONSISTENT),
> then I could consider that a reasonable enough solution.

This happens within a single dlmopen() call.
I think its up to glibc to make sure no one
touches the link-map before ACT_CONSISTENT is
reported. And I think you can also use pthread_self()
to check for yourself from which threads things
are called. So when you see la_dynload(), you
remember pthread_self(). Then you know that:
1. Any la_objopen() call with that pthread_self()
   is "late" unless ACT_CONSISTENT was seen with
   that pthread_self().
2. Any la_objopen() call with different pthread_self()
   is not "late".

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