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

["fweimer at redhat dot com" <sourceware-bugzilla@sourceware.org>]

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

--- Comment #12 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to Stas Sergeev from comment #11)
> (In reply to Florian Weimer from comment #10)
> > I think for experimentation, you can use the link map as a dlopen handle
> > directly, and pass it to dlsym, for example.
> 
> That finally works, thank you.
> So with that and the patches already posted to ML,
> I can at least start prototyping some code.
> 
> 
> > We need to gather consensus that this is the way to do it, and document it.
> > Presently, it's an undocumented implementation detail.
> > 
> > We also need to use a dedicated link map allocator which only reuses, but
> > not frees, the underlying storiage, so that it becomes safe to traverse the
> > _r_debug lists, despite concurrent dlopen/dlcose operation.
> 
> 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 it's
hard to tell how many applications assume this undocumented equivalence.

Maybe we shouldn't commit to the other direction of reuse (casting a dlopen
handle to struct link_map *), that's a separate decision.

> 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
dlopen/dlclose. Introducing that is difficult. Such locks are easily misused,
and there is no precedent for exposing glibc locks in this way.

> > There should also be a way to obtain a stable handle from a link map
> > pointer. Using dlopen with RTLD_NOLOAD seems about right for that.
> 
> So do you want this patch to get that working
> right here right now:
> 
> --- a/elf/dl-open.c
> +++ b/elf/dl-open.c
> @@ -872,7 +872,8 @@ no more namespaces available for dlmopen()"));
>                   DL_NNS is 1 and so any NSID != 0 is invalid.  */
>                || DL_NNS == 1
>                || GL(dl_ns)[nsid]._ns_nloaded == 0
> -              || GL(dl_ns)[nsid]._ns_loaded->l_auditing))
> +              || (GL(dl_ns)[nsid]._ns_loaded->l_auditing &&
> +                                  !(mode & RTLD_NOLOAD))))
>      _dl_signal_error (EINVAL, file, NULL,
>                       N_("invalid target namespace in dlmopen()"));
>  
> I tested that patch and it works.
> Test-suit shows no regressions.

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

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

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