* Ben Cotton:
Another problem of a hardcoded RPATH is security. When an ELF object
contains an RPATH pointed to a directory not managed by the system,
where some malicious actor has write permissions to, it's relatively
easy to execute arbitrary code.
Performance can be also affected, since probing explicitly e.g.
/usr/lib64 through RPATH adds extra open/openat system calls to the
process startup.
Both issues also apply to RUNPATH, not just RPATH. It particularly
impacts s390x due to its many legacy hwcaps subdirectories.
=== Definition of a broken RPATH ===
This change will use the
[
https://github.com/rpm-software-management/rpm/blob/master/scripts/check-...
rpm script] for checking the broken RPATH's.
The categories are:
* standard RPATHs (e.g. `/usr/lib` or `/usr/lib64`); such RPATHs are a
minor issue but are introducing redundant searchpaths without
providing a benefit. They can also cause errors in multilib
environments.
* invalid RPATHs; these are RPATHs which are neither absolute nor
relative filenames and can therefore be a SECURITY risk
* insecure RPATHs; these are relative RPATHs which are a SECURITY risk
* the special `$ORIGIN` RPATHs are appearing after other RPATHs; this
is just a minor issue but usually unwanted
* the RPATH is empty; there is no reason for such RPATHs and they
cause unneeded work while loading libraries
* an RPATH references `..` of an absolute path; this will break the
functionality when the path before `..` is a symlink
$ORIGIN needs to exempted from the absolute and .. checks as well.
I think these rules make sense for RUNPATH, and we should outright ban
RPATH.
I think we also should binutils with --enable-new-tags at configure
time.
Thanks,
Florian