Description of problem:
If any file capabilities are set on an executable, the value of environment
variable LD_LIBRARY_PATH is ignored when that executable is run.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Build a dynamic shared library. Link an executable to that shared library.
Verify that setting LD_LIBRARY_PATH to the directory holding the shared library
allows the executable to run even if the shared library is not in one of the
default search locations.
2. Set a file capability on the executable using setcap
3. The executable will no longer honor the LD_LIBRARY_PATH environment variable
when it is run.
4. Removing the file capabilities from the executable with the undocumented
setcap -r restores normal operation.
The executable is not correctly dynamically linked-- the value of
LD_LIBRARY_PATH is ignored.
The LD_LIBRARY_PATH environment variable should work as expected even though the
file has capability flags set.
That's not a libcap bug but an intentional security feature of glibc. glibc
ignores LD_LIBRARY_PATH (and some other environment variables) when capabilities
are set as someone could overlay some of the functions which the executable
calls with malicious code to p.e. change passwords or whatever. All this would
be done with raised capabilities and would be a major security issue.