RFC: Should the linker warn about and/or control the propagation of audit libraries ?

[Matt Rice]

On Thu, Jul 30, 2026 at 2:28 PM Matt Rice <ratmice@gmail.com> wrote:
>
> > On Thu, Jul 30, 2026 at 4:15 AM Nick Clifton <nickc@redhat.com> wrote:
> > >
> > > Hi Sam,
> > >
> > > > I'm not sure I see a problem: the same issue exists with ELF
> > > > constructors without DT_AUDIT.
> > >
> > > Do these constructors have the potential to intercept and change
> > > symbol resolution though ?  I think that the issue is that audit
> > > libraries are potentially able to perform very low level manipulation
> > > of the run time environment, and so should be used with caution.
> > >
> > >
> > > > That said, the use of DT_AUDIT is so unusual that I'd find a message
> > > > about it slightly interesting.
> > >
> > > I must admit that I would be interested in seeing if there any
> > > projects out there that are using audit libraries for anything
> > > other than debugging or profiling purposes.
> >
>
> I pushed a quickly updated version of the project to codeberg...
>
> https://codeberg.org/ratmice/framework-gccplugin
>
> It isn't fully working as expected but 99% or so...
> For some reason executing the binary works, but ldd does not,
> but likely a glibc issue, haven't probably won't have time for
> debugging ld.so any time soon.

I thought of a simpler example along the same lines as above,
that would be more familiar, and solve a real problem. Rather
than emulating some alien system behavior on gnu toolchains.

Using the same audit method, we could probably reimplement $ORIGIN using
a character sequence that doesn't require arbitrary levels of shell escaping.
for that we could ignore the whole gcc plugin, since it doesn't modify
the pre-processor
path.

Not really going to work on it unless there is interest in it, such as
a way that we could designate
a new character, and provide an audit shim for current gnu systems...