Bug 985569

Summary:	libuser wrongly sets "date of last password change" shadow field to 0 on systems without an rtc
Product:	[Fedora] Fedora	Reporter:	Hans de Goede <hdegoede>
Component:	libuser	Assignee:	Miloslav Trmač <mitr>
Status:	CLOSED ERRATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	20	CC:	kparal, mitr, pwhalen, robatino
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	RejectedBlocker AcceptedFreezeException
Fixed In Version:	libuser-0.60-3.fc20	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-11-10 07:58:56 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	245418, 980649, 980650

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.