+++ 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)
See a request for steps to reproduce in bug #1019850 comment #1.
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
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)