RFC: does ld.so.preload still make sense?

RFC: does ld.so.preload still make sense?

[Adhemerval Zanella Netto]

As comment suggests it should be only used for emergencies and testing,
as it is a non-configurable file path that works even for SUID binaries
(there is no way to disable it nor to change the its patch without 
patching glibc).

It is also not properly document on the manual, although man-pages does
have an entry with a proper explanation.  I am not sure it should be
considered as a security liability, however it is an extra performance
hit on *every* program execution for a very specific and not really
deployed feature.

Is this still useful in current scenarios, as debug tool to fix 
misconfigured systems? Or should we remove it?

Re: RFC: does ld.so.preload still make sense?

[Martin Jambor]

Hello,

On Mon, Jul 24 2023, Adhemerval Zanella Netto via Libc-alpha wrote:
> As comment suggests it should be only used for emergencies and testing,
> as it is a non-configurable file path that works even for SUID binaries
> (there is no way to disable it nor to change the its patch without 
> patching glibc).
>
> It is also not properly document on the manual, although man-pages does
> have an entry with a proper explanation.  I am not sure it should be
> considered as a security liability, however it is an extra performance
> hit on *every* program execution for a very specific and not really
> deployed feature.
>
> Is this still useful in current scenarios, as debug tool to fix 
> misconfigured systems? Or should we remove it?

SUSE now uses it in order to load libpulp[1] into all processes to
facilitate user-space live-patching (when the administrator opts-in by
installing a special package).

So we would be very much against removal of the config file.

Thanks,

Martin


[1] https://github.com/SUSE/libpulp

Re: RFC: does ld.so.preload still make sense?

[Florian Weimer]

* Adhemerval Zanella Netto via Libc-alpha:

> As comment suggests it should be only used for emergencies and testing,
> as it is a non-configurable file path that works even for SUID binaries
> (there is no way to disable it nor to change the its patch without 
> patching glibc).
>
> It is also not properly document on the manual, although man-pages does
> have an entry with a proper explanation.  I am not sure it should be
> considered as a security liability, however it is an extra performance
> hit on *every* program execution for a very specific and not really
> deployed feature.
>
> Is this still useful in current scenarios, as debug tool to fix 
> misconfigured systems? Or should we remove it?

Does the Raspberry Pi still use it?  If I reclal correctly, historically
they used this approach to install their optimized string routines
because they didn't want to patch glibc for some reason.

Thanks,
Florian