Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Cause:
pam_userdb too strictly handled the call to the crypt() function not expecting modern crypt hash formats.
Consequence:
pam_userdb was not able to support any other hash algorithms supported by glibc for the user password hashes.
Fix:
The code handling the crypt() function call was improved.
Result:
pam_userdb module now supports any password hash formats supported by the glibc crypt() function.
Description of problem:
The crypt option definiton in the pam_userdb man page states that if value crypt is used, passwords should be stored in crypt(3) form. It supports, however, DES-crypt only, while crypt() supports a couple of other algorithms too according to the crypt(3) man page.
Version-Release number of selected component (if applicable):
pam-1.1.1-17.el6.x86_64
How reproducible:
always
Steps to Reproduce:
1. $ man pam_userdb
Actual results:
incorrect definition of the crypt option
Expected results:
correct definition of the crypt option
Additional info:
In the PAM version in RHEL 6, there is a constraint before crypt() is called:
if (data.dsize != 13) {
compare = -2;
This constraint matches exactly what is expected from a DES-crypt encrypted password. Its length must be exactly 13 characters. That's why it doesn't support other algorithms even though crypt() does support them and crypt() is used. Some changes to the pam_userdb code would have to be done in order to support other algorithms too.
Looking at PAM in RHEL 7, this constraint is changed along with some other changes in the relevant part of the code, so it's possible that PAM in RHEL 7 supports other algorithms (I didn't try it, that is just what I guess from the code):
if (data.dsize < 13) {
compare = -2;
Man pages for RHEL 6 and RHEL 7 define the crypt option in the same way though.
You can easily create a SHA512 hashed password with python script:
import crypt
crypt.crypt('<password>', '<salt>')
Where salt is $6$<any-16-random-characters>$'
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-2014-1579.html
Description of problem: The crypt option definiton in the pam_userdb man page states that if value crypt is used, passwords should be stored in crypt(3) form. It supports, however, DES-crypt only, while crypt() supports a couple of other algorithms too according to the crypt(3) man page. Version-Release number of selected component (if applicable): pam-1.1.1-17.el6.x86_64 How reproducible: always Steps to Reproduce: 1. $ man pam_userdb Actual results: incorrect definition of the crypt option Expected results: correct definition of the crypt option Additional info: In the PAM version in RHEL 6, there is a constraint before crypt() is called: if (data.dsize != 13) { compare = -2; This constraint matches exactly what is expected from a DES-crypt encrypted password. Its length must be exactly 13 characters. That's why it doesn't support other algorithms even though crypt() does support them and crypt() is used. Some changes to the pam_userdb code would have to be done in order to support other algorithms too. Looking at PAM in RHEL 7, this constraint is changed along with some other changes in the relevant part of the code, so it's possible that PAM in RHEL 7 supports other algorithms (I didn't try it, that is just what I guess from the code): if (data.dsize < 13) { compare = -2; Man pages for RHEL 6 and RHEL 7 define the crypt option in the same way though.