Bug 696748

Summary: [RFE] Make access to /proc/$PID/fd after setuid behaviour tunable
Product: Red Hat Enterprise Linux 5 Reporter: J.H.M. Dassen (Ray) <rdassen>
Component: kernelAssignee: Red Hat Kernel Manager <kernel-mgr>
Status: CLOSED WONTFIX QA Contact: Red Hat Kernel QE team <kernel-qe>
Severity: medium Docs Contact:
Priority: medium    
Version: 5.6CC: awiggins, rbinkhor
Target Milestone: rcKeywords: FutureFeature, Triaged
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-07-29 15:48:39 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 554476    

Description J.H.M. Dassen (Ray) 2011-04-14 18:59:32 UTC
2. What is the nature and description of the request?

The customer uses a custom version of kerberos that stores tickets in a PIPE
cache instead of a FILE cache. Starting in RHEL 5.6., kerberos applications
stopped working when using this custom kerberos library. The file descriptors
for the PIPE cache from pam_krb5.so (which is also custom-compiled against
their library) are not passed to gnome-session and its children, so kerberos
doesn't work. Apparently this behavior is due to bz 617707. The customer is
hoping to have a way to toggle this behavior so that they can get the 'classic'
behavior back.


3. Why does the customer need this? (List the business requirements here)

On-site security requirements force them to use the custom kerberos library, so
not using it is not an option. They are currently building a custom kernel
without patch from bz 617707. However, maintaining a custom kernel is a lot of
overhead for them, and continuing to use a pre-5.6 kernel will only last until
they have a kernel with security fixes that are deemed necessary.


4. How would the customer like to achieve this? (List the functional
requirements here)

The kernel would have a configurable option (a boot option or a sysctl control
or similar) that would restore the 'classic' behavior.


5. For each functional requirement listed in question 4, specify how Red Hat
and the customer can test to confirm the requirement is successfully
implemented.

The customer could test easily by setting the custom kernel option and then
verifying that their application works.


6. Is there already an existing RFE upstream or in Red Hat bugzilla?

No.


7. How quickly does this need resolved? (desired target release)

RHEL 5.7 would be optimal.


8. Does this request meet the RHEL Inclusion criteria (please review)

Yes


9. List the affected packages

kernel


10. Would the customer be able to assist in testing this functionality if
implemented?

Yes