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.