Bug 1019855 - passwd -S <username> output is one day off
passwd -S <username> output is one day off
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: passwd (Show other bugs)
All Unspecified
low Severity low
: rc
: ---
Assigned To: Miloslav Trmač
BaseOS QE Security Team
Depends On: 1019850
  Show dependency treegraph
Reported: 2013-10-16 09:51 EDT by John Trowbridge
Modified: 2013-11-21 14:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1019850
Last Closed: 2013-11-21 14:11:34 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description John Trowbridge 2013-10-16 09:51:44 EDT
+++ 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:

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 16:37:53 EDT
See a request for steps to reproduce in bug #1019850 comment #1.
Comment 2 John Trowbridge 2013-10-21 17:22:32 EDT
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

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
Comment 4 Miloslav Trmač 2013-11-21 14:11:34 EST
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)

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