Problem: An attacker could cause an application to use a corrupted shared library Fix By: Moving the shared libraries needed to a proper location Waive If: The application uses shared libraries held in non-standard locations Waive If: The linker does not support --enable-new-dtags Example: FAIL: run-path test because the DT_RPATH/DT_RUNPATH dynamic tag is corrupt Example: MAYB: run-path test because the DT_RPATH/DT_RUNPATH dynamic tag exists but is empty Example: FAIL: run-path test because the DT_RPATH/DT_RUNPATH dynamic tag contains a path that does not start with /usr Example: FAIL: run-path test because the DT_RPATH/DT_RUNPATH dynamic tag has a path that contains '..' Example: FAIL: run-path test because the DT_RPATH/DT_RUNPATH dynamic tag has $ORIGIN after a non-$ORIGIN path
An application that uses shared libraries contains information on how to locate those libraries. This information is a list of directories which should be searched for the libraries. The test checks that the list is secure.
The test actually covers several different aspects, such as all directory paths must be absolute, start with /usr and must not contain ... If any of these rules are broken then an attacker might be able to exploit the search paths to force the application to load their own, corrupted version of a shared library.
In addition if the --profile=rawhide option has been enabled then the presence of the DT_RPATH dynamic tag will generate a MAYB result, since in Fedora the DT_RUNPATH tag is preferred. (The two tags only differ in when they are evaluated by the program loader). The DT_RUNPATH dynamic tag should be generated by default, if it is needed, but in some cases it may be necessary to add the --enable-new-dtags option to the linker command line, or the -Wl,--enable-new-dtags option if you use gcc to drive the linker.
If necessary the test can be disabled via the --skip-run-path option and re-enabled via the --test-run-path option.