Bug 1032140 - vlock doesn't perform PAM account management or credential reinitialization
vlock doesn't perform PAM account management or credential reinitialization
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: kbd (Show other bugs)
Unspecified Unspecified
medium Severity medium
: rc
: ---
Assigned To: Vitezslav Crhonek
Depends On: 913311
Blocks: 1029374
  Show dependency treegraph
Reported: 2013-11-19 10:40 EST by Nalin Dahyabhai
Modified: 2014-06-18 03:33 EDT (History)
8 users (show)

See Also:
Fixed In Version: kbd-1.15.5-8.el7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 913311
Last Closed: 2014-06-13 06:55:21 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Nalin Dahyabhai 2013-11-19 10:40:45 EST
+++ This bug was initially created as a clone of Bug #913311 +++

Description of problem:
The 'vlock' command no longer performs PAM account management (authorization checking) or credential reinitialization.

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

How reproducible:

Steps to Reproduce:
1. run 'vlock' or 'vlock -a'
Actual results:
After checking the user's password, 

Expected results:
After calling pam_authenticate(), vlock should be calling pam_acct_mgmt(), and if that fails, rejecting the unlock attempt.  If it succeeds, it should be calling pam_setcred() with the PAM_REINITIALIZE_CRED flag.

--- Additional comment from Fedora End Of Life on 2013-04-03 13:57:02 EDT ---

This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:

--- Additional comment from Vadim Raskhozhev on 2013-04-12 14:25:21 EDT ---

A possible workaround is to create a file /etc/pam.d/vlock with something like

auth       include      system-auth
account    required     pam_permit.so

(this is taken from vlock-1.3-33.fc18).

--- Additional comment from Nalin Dahyabhai on 2013-04-12 14:32:40 EDT ---

That'd take care of part of it (as in bug #913309), but without code changes it's not going to detect things like passwords having expired or (depending on how it's done) accounts being locked.

--- Additional comment from Walter Francis on 2013-07-02 10:01:29 EDT ---

vlock on F19 for me just goes nuts saying invalid password when ran until the workaround in comment 2 and now it works as expected for me, at least it the case of "Normal user, valid password, ran vlock, unlocked."  Don't know about the other use cases.

--- Additional comment from Vitezslav Crhonek on 2013-11-13 09:14:28 EST ---

--- Additional comment from Vitezslav Crhonek on 2013-11-13 09:18:00 EST ---

Nalin, I'm not familiar with PAM API, would the patch above suffice?

--- Additional comment from Nalin Dahyabhai on 2013-11-13 11:26:42 EST ---

The formatting for the error reporting looks a bit weird, but yes, it roughly matches what the old vlock did, and should work for our purposes.

One thing that the PAM docs (pam_acct_mgmt(3)) recommend is calling pam_chauthtok() if pam_acct_mgmt() returns PAM_NEW_AUTHTOK_REQD and the application has the ability to walk the user through changing their password, but that's less urgent -- the old vlock didn't do that, either.
Comment 3 Ludek Smid 2014-06-13 06:55:21 EDT
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.

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