Bug 448594

Summary: Use of file capabilities disables LD_LIBRARY_PATH
Product: [Fedora] Fedora Reporter: Kevin Arunski <karunski>
Component: libcapAssignee: Karsten Hopp <karsten>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 9   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-05-28 09:11:50 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Kevin Arunski 2008-05-27 18:55:32 UTC
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):

How reproducible:

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:

Comment 1 Karsten Hopp 2008-05-28 09:11:50 UTC
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.