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

Matt Rice <[email protected]> Wed, 29 Jul 2026 07:17:08 -0700
Newsgroups gmane.comp.gnu.binutils
Message-ID <CACTLOFpUW9sFfQFbJHQKvUmH2UsczNH=Lks6LqNtQYwBo5AwrQ@mail.gmail.com>
On Tue, Jul 28, 2026 at 4:41 AM Matt Rice <[email protected]> wrote:
>
>
> One last thing, on solaris the rtld implementation if I recall
> correctly was that for setuid/setgid binaries
> these libraries were only loaded from a "trusted location" underneath
> `/lib/secure/`.
> You could consider some kind of trusted location under which you don't
> emit the propagation limit.
> That would have worked alternately for my case where I had a system
> wide audit library which was commonly linked.
>

Having slept on this thought, I think this was a terrible idea. To
conflate the trusted location
which has the side effect of allowing setuid/setgid and also avoiding
this error.
We could just have a configurable path which avoids the error, but
directory paths
with special behaviors are actually a bit annoying at a system level.
(because every distro wants
a different place)

I guess the simple solution is just having an
/etc/ld/audit.propagation.allow list,
 which just contains a list of file paths which shouldn't complain.

The way that my audit library worked was that it adds new elf
substitution sequences (similar but different
from the substitution sequences built into elf like ${ORIGIN}, ...)
and it is assumed these will work for dlopen too
So it is pretty well assumed that these audit libraries will end up to
linked in to most programs on the system.