Bug 975074

Summary: pam_pwhistory does not work with SELinux
Product: [Fedora] Fedora Reporter: Tomas Mraz <tmraz>
Component: pamAssignee: Tomas Mraz <tmraz>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: chanson, dwalsh, mgrepl, tmraz
Target Milestone: ---Keywords: FutureFeature, SELinux
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: pam-1.1.6-12.fc20 Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: 974700 Environment:
Last Closed: 2013-08-07 16:05:00 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Tomas Mraz 2013-06-17 14:52:16 UTC 
+++ This bug was initially created as a clone of Bug #974700 +++

Description of problem:
The pam_pwhistory module does not work with SELinux because it is does not utilize the SELinux unix_* helpers.

Version-Release number of selected component (if applicable):
pam-1.1.1-13

How reproducible:
Always

Steps to Reproduce:
1. Enable pam_pwhistory in with SELinux
2. Create a test user and expire the password with chage
3. Attempt to login as user with expired password

Actual results:
User password is changed, but I believe PAM_USER_UNKOWN is being returned to the PAM stack because of the failure to get data from the shadow file. User thinks password change has failed when it has succeeded.

Expected results:
User should change password and then be logged into the login session.

Additional info:
This would seem to be important if the remember functionality of pam_unix is being phased out in favor of pam_pwhistory module.

--- Additional comment from Tomas Mraz on 2013-06-17 16:50:38 CEST ---

This is by no means simple change. The module would need to have a new helper that would transfer the password hash from /etc/shadow to the /etc/security/opasswd. And the /etc/security/opasswd would have to be handled with the same restrictions as the /etc/shadow, otherwise the helper could be used to leak the hash from the shadow to a file with less stringent access restrictions.

I suppose that for RHEL-6 it would be probably much easier to have a boolean (off by default) that would allow direct access to the /etc/shadow for applications that call PAM password modules.