When setting / updating a password with libuser (as initial-setup does) libuser will set the "date of last password change" /etc/shadow field for the user. But on some arm systems there is no rtc, so often when initial-setup runs, the date is 1-1-1970, and the contents of this field is the date of the last change in days since 1-1-1970, iow on systems without an rtc, which have been running for less then a day, libuser will set this field to 0. But 0 is a reserved value and means: the user MUST change his password on first login, so what happens is: -user starts arm fedora image on arm development board without an rtc. -user creates a user in initial-setup -user logs in as the just created user, and must now immediately change his password Most tools do not set the "date of last password change" field, at all, iow the leave it empty (atleast when not using password aging), but if libuser must set it, the it should check it is not setting it to 0, and in that case set it to 1 instead since 0 is a reserved value with a special meaning.
Good catch, thanks for the report. The field should probably be set to empty ("-1"); "1" would mean that if any password expiration is set, the password will most likely expire as soon as the date is set correctly.
(In reply to Miloslav Trmač from comment #1) > Good catch, thanks for the report. > > The field should probably be set to empty ("-1"); That would work too, TBH I wonder why libuser sets it at all even though password aging is disabled ( "maximum password aging == 99999), other utilities don't seem to set it at all in this case, ie running "passwd" and setting a new password will leave the field empty. > "1" would mean that if any > password expiration is set, the password will most likely expire as soon as > the date is set correctly. No, 1 + 99999 is 100000 days from 1-1-1970, which is still a while away :) You are right of course that if password aging is enabled and the date is fsck-ed up when libuser runs bad things will happen, not sure if we should even try to handle that case though.
Discussed at 2013-09-04 blocker review meeting [1]. This doesn't violate any of the F20 alpha release criteria and thus is rejected as a release blocking bug for alpha. However, a tested fix would be considered past freeze. [1] http://meetbot.fedoraproject.org/fedora-blocker-review/2013-09-04/
This bug appears to have been reported against 'rawhide' during the Fedora 20 development cycle. Changing version to '20'. More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora20
libuser-0.60-3.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/libuser-0.60-3.fc20
Package libuser-0.60-3.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing libuser-0.60-3.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-19208/libuser-0.60-3.fc20 then log in and leave karma (feedback).
libuser-0.60-3.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.