Bug 1019855

Summary:	passwd -S <username> output is one day off
Product:	Red Hat Enterprise Linux 5	Reporter:	John Trowbridge <jtrowbri>
Component:	passwd	Assignee:	Miloslav Trmač <mitr>
Status:	CLOSED WONTFIX	QA Contact:	BaseOS QE Security Team <qe-baseos-security>
Severity:	low	Docs Contact:
Priority:	low
Version:	5.10	CC:	jtrowbri
Target Milestone:	rc
Target Release:	---
Hardware:	All
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:	1019850	Environment:
Last Closed:	2013-11-21 19:11:34 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:
Bug Depends On:	1019850
Bug Blocks:

Description John Trowbridge 2013-10-16 13:51:44 UTC

+++ This bug was initially created as a clone of Bug #1019850 +++

Description of problem:
When changing a password and then running 'passwd -S user_id' the date
shows up as yesterday. 


Version-Release number of selected component (if applicable):
passwd 0.77-4.el6_2.2.x86_64

How reproducible:
Easily reproducible

Steps to Reproduce:
1. passwd testuser
2. passwd -S testuser


Actual results:
testuser PS 2013-10-15 0 99999 7 -1 (Password set, MD5 crypt.)

Expected results:
testuser PS 2013-10-16 0 99999 7 -1 (Password set, MD5 crypt.)

Additional info:
passwd/passwd-0.77/libuser.c

287                         sp_lstchg = (time_t) ent_value_int64(ent, LU_SHADOWLASTCHANGE);
..

324                         if (shadow) {
325                                 sp_lstchg = sp_lstchg * 24L * 3600L;
326                                 localtime_r(&sp_lstchg, &tm);
327                                 strftime(date, sizeof(date), "%Y-%m-%d", &tm);
328                                 printf("%s %s %s %lld %lld %lld %lld (%s)\n", realname, status,
329                                         date, sp_min, sp_max, sp_warn, sp_inact, msg);
..

There are a few conversions that happen in order to get to the final value, which includes the last changed value pulled, and run through localtime_r. Something in the conversion is probably off a bit (or doesnt compensate for tz info, DST, whatever)

Comment 1 Miloslav Trmač 2013-10-21 20:37:53 UTC

See a request for steps to reproduce in bug #1019850 comment #1.

Comment 2 John Trowbridge 2013-10-21 21:22:32 UTC

Here are the requested reproduction steps:

[root@rhel ~]# date
Mon Oct 21 16:40:06 EDT 2013
[root@rhel ~]# useradd testuser
[root@rhel ~]# passwd testuser
Changing password for user testuser.
New password: 
BAD PASSWORD: it is too short
BAD PASSWORD: is too simple
Retype new password: 
passwd: all authentication tokens updated successfully.
[root@rhel ~]# passwd -S testuser
testuser PS 2013-10-20 0 99999 7 -1 (Password set, SHA512 crypt.)
You have new mail in /var/spool/mail/root
[root@rhel ~]# grep testuser /etc/shadow
testuser:$6$aCg.SHv5$IBaMt73GZoZnDW22M77MYL9LHWqM3Gev9uOUPS.nO/QfG6WgCMR3KMJh88Dbw8/pJoUNuP0YGaivJ9MqaZ/Ru0:15999:0:99999:7:::

The following python code shows that the number of days in /etc/shadow gives the expected date:

>>> import datetime
>>> epoch = datetime.date(1970,1,1)
>>> shadow = epoch + datetime.timedelta(15999)
>>> shadow
2013-10-21

Comment 4 Miloslav Trmač 2013-11-21 19:11:34 UTC

Ultimately the only real fix is to start storing the last change time in more precision than "24 hours" (filed now as bug 1033252), which I'm afraid can't happen in RHEL 5.

For RHEL 5, we could make the output more likely to be correct but still not reliable, at the cost of breaking compatibility (... in an undocumented output format, true); I don't think this is worth it, so closing wontfix (but please do reopen if you disagree.)

(See bug 1019850 comment 4 for the full rationale, only copying the highlight here)