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): kernel-2.6.25-14.fc9.x86_64 libcap-2.06-4.fc9.x86_64 glibc-2.8-3.x86_64 How reproducible: Always 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. Actual results: The executable is not correctly dynamically linked-- the value of LD_LIBRARY_PATH is ignored. Expected results: The LD_LIBRARY_PATH environment variable should work as expected even though the file has capability flags set. Additional info:
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.