Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 985569 - libuser wrongly sets "date of last password change" shadow field to 0 on systems without an rtc
Summary: libuser wrongly sets "date of last password change" shadow field to 0 on syst...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: libuser
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Miloslav Trmač
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: RejectedBlocker AcceptedFreezeException
Depends On:
Blocks: ARMTracker F20AlphaBlocker F20AlphaFreezeException
TreeView+ depends on / blocked
 
Reported: 2013-07-17 19:01 UTC by Hans de Goede
Modified: 2013-11-10 07:58 UTC (History)
4 users (show)

Fixed In Version: libuser-0.60-3.fc20
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-11-10 07:58:56 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)

Description Hans de Goede 2013-07-17 19:01:37 UTC 
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 20:15:33 UTC 
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 06:42:00 UTC 
(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 17:04:33 UTC 
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 16:47:31 UTC 
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 14:06:31 UTC 
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 20:33:06 UTC 
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 07:58:56 UTC 
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.