Bug 696748 - [RFE] Make access to /proc/$PID/fd after setuid behaviour tunable
Summary: [RFE] Make access to /proc/$PID/fd after setuid behaviour tunable
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel
Version: 5.6
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Red Hat Kernel Manager
QA Contact: Red Hat Kernel QE team
URL:
Whiteboard:
Depends On:
Blocks: 554476
TreeView+ depends on / blocked
 
Reported: 2011-04-14 18:59 UTC by J.H.M. Dassen (Ray)
Modified: 2018-11-14 13:49 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-07-29 15:48:39 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 617707 1 None None None 2021-01-20 06:05:38 UTC

Internal Links: 617707

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


Note You need to log in before you can comment on or make changes to this bug.