Bug 804123 - sudo does not call pam_close_session() or pam_end()
sudo does not call pam_close_session() or pam_end()
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: sudo (Show other bugs)
x86_64 Linux
high Severity high
: rc
: 6.4
Assigned To: Daniel Kopeček
Aleš Mareček
Depends On:
Blocks: 782183
  Show dependency treegraph
Reported: 2012-03-16 11:14 EDT by Dustin Black
Modified: 2013-02-21 04:44 EST (History)
5 users (show)

See Also:
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:
Last Closed: 2013-02-21 04:44:15 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:0363 normal SHIPPED_LIVE sudo bug fix and enhancement update 2013-02-20 15:52:59 EST

  None (edit)
Description Dustin Black 2012-03-16 11:14:47 EDT
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):

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:
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 03:17:57 EDT
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-05 21:56:43 EDT
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 04:44:15 EST
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.


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