Bug 804123

Summary: sudo does not call pam_close_session() or pam_end()
Product: Red Hat Enterprise Linux 6 Reporter: Dustin Black <dblack>
Component: sudoAssignee: Daniel Kopeček <dkopecek>
Status: CLOSED ERRATA QA Contact: Aleš Mareček <amarecek>
Severity: high Docs Contact:
Priority: high    
Version: 6.2CC: amarecek, cww, dblack, ksrot, pvrabec
Target Milestone: rc   
Target Release: 6.4   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: sudo-1.8.6p3-1.el6 Doc Type: Bug Fix
Doc Text:
Cause: Passing a different PAM handle to PAM API functions where the same handle should be used. This is caused by initializing the global variable holding the PAM handle from a child process, which has a separate address space and thus the initialization has no effect on the parent's PAM handle where the pam_end_sessions functions is called. Consequence: (from comment #3) A module may rely on being called at session close in order to release resources or make important administrative changes, which now won't happen. Fix: Fixed by rebasing to a newer upstream version which uses the PAM API correctly, i.e. initializes one PAM handle and uses it in all related PAM API function calls. Result: PAM session is closed correctly.
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-02-21 09:44:15 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 782183    

Description Dustin Black 2012-03-16 15:14:47 UTC
Description of problem:
When configured to use the "session" function of a PAM module, sudo calls pam_open_session(), but never calls pam_close_session() or pam_end() to close the session.

Version-Release number of selected component (if applicable):
sudo-1.7.4p5-7.el6

How reproducible:
With the code instrumented to show the pid and status of the pamh handle in both places, this is clear:

$ sudo true
** pam_init: pid 24820, pamh is set
** pam_end_session: pid 24819, pamh is null

Steps to Reproduce:
1.
2.
3.
  
Actual results:
pam_close_session() or pam_end() are never called to end the session


Expected results:
pam_close_session() or pam_end() are called appropriately

Additional info:
In auth/pam.c, there is this:

static pam_handle_t *pamh;	/* global due to pam_prep_user() */

This defines a static global variable to hold the PAM handle, which is initialized in pam_init(), and should be used in pam_end_session() to end the session. The use of the global variable for coordination is broken, however, because pam_init() is called in a subprocess, whereas pam_end_session() is called later in the parent process; thus, the handle is always NULL when pam_end_session() runs, and sudo never calls the PAM session close method.

Comment 2 Karel Srot 2012-07-31 07:17:57 UTC
Hi,
does this bug has any consequences that can be observed? I mean, is there any memory leak, error message,.. Can we check the bug/fix in some "common way", different from mentioned approach, gdb or systemtap...?

Comment 3 Dustin Black 2012-09-06 01:56:43 UTC
The issue was identified through code analysis, rather than through any known ill effect, afaik. The argument is that sudo does not follow PAM conventions, and it could prevent PAM modules from working correctly, in perhaps significant ways. A module may rely on being called at session close in order to release resources or make important administrative changes, which now won't happen. This is especially a concern considering that this is a security-critical component.

Comment 9 errata-xmlrpc 2013-02-21 09:44:15 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-0363.html