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.
Bug 629001 - Users created after installation during firstboot setup have MD5 password hashes in /etc/shadow instead of SHA512
Summary: Users created after installation during firstboot setup have MD5 password has...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libuser
Version: 6.0
Hardware: All
OS: Linux
urgent
medium
Target Milestone: rc
: ---
Assignee: Miloslav Trmač
QA Contact: Eduard Benes
URL:
Whiteboard:
Depends On:
Blocks: 580448
TreeView+ depends on / blocked
 
Reported: 2010-08-31 15:51 UTC by Eduard Benes
Modified: 2010-11-10 21:05 UTC (History)
12 users (show)

Fixed In Version: libuser-0.56.13-4.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-11-10 21:05:10 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Eduard Benes 2010-08-31 15:51:15 UTC 
Description of problem:
All users on the system should have SHA512 password pashes in /etc/shadow. But 
Normal users created after installation by firstboot have MD5 password hashes in /etc/shadow. This might be a bug in anaconda, libuser or authconfig. Using anaconda component as a good start point (authconfig--updateall).

Version-Release number of selected component (if applicable):
RHEL 6.0 Snapshot 13 

authconfig-6.1.4-6.el6
firstboot-1.110.8-1.el6
libuser-0.56.13-3.el6


How reproducible:
always

Steps to Reproduce:
1. Start fresh install of a RHEL 6.0 system (KVM virt will work)
2. After reboot add a normal user "foo" in a firstboot setup screen
3. Finish installation and log in
4. As a root check the password hash:
# grep foo /etc/shadow
foo:$1$gdkxBaw7$NUOVWchuVcyZkGPXna7fh1:14852:0:99999:7:::

Actual results:
MD5 password hashes in /etc/shadow for users added during firstboot setup after installation. This should be SHA512.

Expected results:
Only SHA512 password hashes in /etc/shadow
# grep crypt_style /etc/libuser.conf
crypt_style = sha512

Additional info:
Anaconda logs show authconfig was called with sha512 (maybe should be called with --updateall?):
# less /var/log/anaconda.program.log shows:
10:50:19,354  INFO program: Running... /usr/sbin/authconfig --update --nostart --enableshadow --passalgo=sha512 --enablefingerprint

There is a md5 in libuser.conf after installation:
# grep crypt_style /etc/libuser.conf
crypt_style = md5

Using --updateall instead of --update seems to do the job:
# authconfig --updateall --passalgo=sha512
# grep crypt_style /etc/libuser.conf
crypt_style = md5

# authconfig --updateall --passalgo=sha512
# grep crypt_style /etc/libuser.conf
crypt_style = sha512
Comment 1 David Cantrell 2010-08-31 17:48:34 UTC 
pykickstart just passes the arguments from the kickstart 'authconfig' command to the actual authconfig command on the system.  If --update is not working, that would be an authconfig bug.
Comment 3 Chris Lumens 2010-08-31 21:31:44 UTC 
As was suspected, the problem here is that --update does not modify /etc/libuser.conf, whereas --updateall does.  I have confirmed this by running strace against the authconfig binary from tty2 in anaconda, chrooted into /mnt/sysimage, and right after anaconda runs authconfig itself.

The reason your /etc/libuser.conf has crypt_style = md5 is because this is what the default libuser.conf provided by the libuser package says.
Comment 4 Tomas Mraz 2010-09-01 08:31:29 UTC 
But is this really a regression? When this worked correctly? This is caused by having sha512 in the default PAM configuration and md5 in the default libuser configuration. Authconfig does not correctly synchronize the settings in such case, but it never did so. I'd say that the easiest fix now would be to make sha512 as default in /etc/libuser.conf and to fix authconfig in 6.1.
Comment 5 Tomas Mraz 2010-09-01 08:39:09 UTC 
Moving to libuser. The authconfig bug is essentially the same as bug 624159.
Comment 6 Eduard Benes 2010-09-01 08:54:33 UTC 
Short summary is to change md5 to sha512 as a default crypt_style in /etc/libuser.conf
Comment 12 releng-rhel@redhat.com 2010-11-10 21:05:10 UTC 
Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.
Note You need to log in before you can comment on or make changes to this bug.