What were you trying to do that didn't work?

When the default kickstart is used (but most likely in any kickstart where the command rootpw is used) the root password gets set/changed. This change seems to update only the has of the password (second field in /etc/shadow) but does not update the last date in wich the password was changed (third filed in /etc/shadow): we think this must be quite wrong. Also the third field seems to become emptied out if something was there like the previous last changed date (when we set it inside of the image to be deployed), thus rendering the password expired apparently, if we have expirations set in the 4th and subsequent fields.

What is the impact of this issue to you?

It is going to render previously set password expirations settings behave wrongly/unexpectedly, in particular setting the root password to something while it being treated as expired by PAM so that it's not possible to login as root then.

Please provide the package NVR for which the bug is seen:

How reproducible is this bug?:

Steps to reproduce

1. set inside of the image a root password with all fields about password expiration (3, 4, 5, 6 and 7th fields)
2. use rootpw to set a new password
3. the third field in /etc/shadow will be empty, basically not setting the date of when rootpw has changed it, which should be the case, in addition if there are expiration fields set, those will make this password automatically expired then (which is also unclear if correct at all, as the man page of shadow 5 states taht empty field should actually not correspond to expired pass)

Expected results

The third field or /etc/shadow should contain the date of the execution of the rootpw command and not empty.

Actual results

The third field of /etc/shadow is instead empty "::"