Bug 985569 - libuser wrongly sets "date of last password change" shadow field to 0 on systems without an rtc
libuser wrongly sets "date of last password change" shadow field to 0 on syst...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: libuser (Show other bugs)
20
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Miloslav Trmač
Fedora Extras Quality Assurance
RejectedBlocker AcceptedFreezeException
:
Depends On:
Blocks: ARMTracker F20AlphaBlocker F20AlphaFreezeException
  Show dependency treegraph
 
Reported: 2013-07-17 15:01 EDT by Hans de Goede
Modified: 2013-11-10 02:58 EST (History)
4 users (show)

See Also:
Fixed In Version: libuser-0.60-3.fc20
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-11-10 02:58:56 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Hans de Goede 2013-07-17 15:01:37 EDT
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.
Comment 1 Miloslav Trmač 2013-07-17 16:15:33 EDT
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.
Comment 2 Hans de Goede 2013-07-18 02:42:00 EDT
(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.
Comment 3 Kamil Páral 2013-09-04 13:04:33 EDT
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/
Comment 4 Fedora End Of Life 2013-09-16 12:47:31 EDT
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
Comment 5 Fedora Update System 2013-10-16 10:06:31 EDT
libuser-0.60-3.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/libuser-0.60-3.fc20
Comment 6 Fedora Update System 2013-10-17 16:33:06 EDT
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).
Comment 7 Fedora Update System 2013-11-10 02:58:56 EST
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.

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