[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 #28 from Stas Sergeev <stsp at users dot sourceforge.net> ---
(In reply to Jonathon Anderson from comment #27)
> There *will* be auditors that will not function properly under these
> restrictions.

Where would they come from and how could
they became loaded by this API?


> At the very least there needs to be some kind of flag
> presented to the auditor at la_version-time to let it know that it has been
> loaded in this (very) degraded state, so the auditor has a chance to refuse
> to load.

Hmm, not really sure there are flags in
la_version(). But I can instead disallow
loading of such auditor and return an error.


> So, IIUC you have an solib plugin (i.e. you don't control the application)
> where you want/need to customize (a) the location the solib is loaded (or
> where what the solib loads is loaded?) with la_premap and (b) the paths that
> your plugin loads with la_objsearch.

a - yes
b - no

> Solibs are "position-independent" and should work no matter where they are
> loaded (unless you're doing *really* dangerous and non-portable tricks with
> function pointers).

I need that to make the 64bit solib to
cooperate with 32bit VM. The memory of
that VM is mapped to 64bit space. I need
to map the lib to that window, but it should
be relocated as if it is in the first 4Gb.
For that I need 2 extensions instead of just 1.
They are in that patch-set. But I am going
to split it into multiple patches for easier
understanding by reviewers. As currently no
one understands it, but this is simply because
the patch is too big.

> (b) gives me bad vibes,

Same here, I am not planning b.

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