| |
@@ -962,15 +962,13 @@
|
| |
|
| |
== Beware of Rpath
|
| |
|
| |
- Sometimes, code will hardcode specific library paths when linking binaries (using the -rpath or -R flag). This is commonly referred to as an rpath. Normally, the dynamic linker and loader (ld.so) resolve the executable's dependencies on shared libraries and load what is required. However, when -rpath or -R is used, the location information is then hardcoded into the binary and is examined by ld.so in the beginning of the execution. Since the Linux dynamic linker is usually smarter than a hardcoded path, we usually do not permit the use of rpath in Fedora.
|
| |
+ Sometimes, code will hardcode specific library paths when linking binaries or libraries (using the -rpath or -R flag). This is commonly referred to as an rpath. Normally, the dynamic linker and loader (ld.so) resolve the object's dependencies on shared libraries and load what is required. However, when -rpath or -R is used, the location information is then hardcoded into the object and is examined by ld.so in the beginning of the execution.
|
| |
|
| |
- There is a tool called _check-rpaths_ which is included in the _rpmdevtools_ package. It is a good idea to add it to the `+%__arch_install_post+` macro in your `+~/.rpmmacros+` config file:
|
| |
+ While rpath can be used for non-standard directories, such as a place containing the private libraries of a project, when it points to a value already provided by the search path of ld.so, it changes the hierarchy of the search by placing the system defaults first. This can lead to various issues, such as LD_LIBRARY_PATH overrides not working, incomplete dependency resolution, loading of the wrong libraries etc.
|
| |
|
| |
- ....
|
| |
- %__arch_install_post \
|
| |
- /usr/lib/rpm/check-rpaths \
|
| |
- /usr/lib/rpm/check-buildroot
|
| |
- ....
|
| |
+ 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, since /usr/lib64 is part of ld.so's default search path.
|
| |
+
|
| |
+ In Fedora we forbid the usage of rpath values that point to directories where the dynamic linker and loader search for by default. There is a tool called _check-rpaths_ which runs as a buildroot policy script after %install, that will check for common rpath issues.
|
| |
|
| |
When _check-rpaths_ is run, you might see output like this:
|
| |
|
| |
@@ -980,9 +978,11 @@
|
| |
|
| |
Any rpath flagged by check-rpaths *MUST* be removed.
|
| |
|
| |
+ However if you believe your package's rpath usage is correct, the buildroot policy script can be disabled by adding `+%global __brp_check_rpaths %{nil}+` in your SPEC file.
|
| |
+
|
| |
=== Rpath for Internal Libraries
|
| |
|
| |
- When a program installs internal libraries they are often not installed in the system path. These internal libraries are only used for the programs that are present in the package (for example, to factor out code that's common to the executables). These libraries are not intended for use outside of the package. When this occurs, it is acceptable for the programs within the package to use an rpath to find these libraries.
|
| |
+ When a program installs internal libraries they are often not installed in the system path. These internal libraries are only used for the programs that are present in the package (for example, to factor out code that's common to the executables) or for plugins built using the package's shared libraries. These libraries are not intended for use outside of the package or its plugins. When this occurs, it is acceptable for the programs within the package to use an rpath to find these libraries.
|
| |
|
| |
Example:
|
| |
|
| |
@@ -1023,6 +1023,8 @@
|
| |
sed -i 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' libtool
|
| |
....
|
| |
|
| |
+ * If the application uses CMake add the -DCMAKE_SKIP_INSTALL_RPATH:BOOL=YES option to %cmake.
|
| |
+
|
| |
* Sometimes, the code/Makefiles can be patched to remove the _-rpath_ or _-R_ flag from being called. This is not always easy or sane to do, however.
|
| |
* As a last resort, Fedora has a package called _chrpath_. When this package is installed, you can run `+chrpath --delete+` on the files which contain rpaths. So, in our earlier example, we'd run:
|
| |
|
| |
churchyard commented 2 years ago
One thing from me: Using
%global __brp_check_rpaths %{nil}MUST be accompanied with an explaining comment.