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
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
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. |