RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1145256 - Document (passwd -S), including time zone usage
Summary: Document (passwd -S), including time zone usage
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: passwd
Version: 7.0
Hardware: All
OS: Linux
unspecified
low
Target Milestone: rc
: ---
Assignee: Jiri Kucera
QA Contact: Jan Houska
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-09-22 16:37 UTC by James
Modified: 2019-08-06 13:11 UTC (History)
2 users (show)

Fixed In Version: passwd-0.79-5.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-08-06 13:11:12 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
CentOS 0007603 0 None None None Never
Red Hat Product Errata RHBA-2019:2257 0 None None None 2019-08-06 13:11:19 UTC

Description James 2014-09-22 16:37:35 UTC 
Description of problem: Originally reported by Jason_P on CentOS bug forum (ID #0007603):
https://bugs.centos.org/view.php?id=7603

/etc/shadow stores the number of days since the epoch of a password change.  This equates to midnight of that day.  When `passwd -S` is invoked this number is passed through localtime_r which will add or subtract hours based on the local time zone.  If this occurs in a "minus zone", the previous day is reported.


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:

1) Set your /etc/localtime to any zone that is GMT-1 to GMT-12.
2) View your last password change with `passwd -S`
3) Compare the value to that of /etc/shadow

Actual results:

[james@localhost ~]$ ls -la /etc/localtime
lrwxrwxrwx. 1 root root 38 Sep 18 10:12 /etc/localtime -> ../usr/share/zoneinfo/America/New_York
[james@localhost ~]$ sudo grep james /etc/shadow
[sudo] password for james:
james:$6[removed]:16331:0:99999:7:::
[james@localhost ~]$ sudo passwd -S james
james PS 2014-09-17 0 99999 7 -1 (Password set, SHA512 crypt.)


Expected results:

16331 days * 24 hours/day * 3600 seconds/hour = 1410998400 seconds
1410998400 seconds since the epoch is "Thu, 18 Sep 2014 00:00:00 GMT" not "2014-09-17".  The correct response is 2014-09-18.


Additional info:

Based on the source RPM for passwd, maybe change libuser.c from:
319,320c319
< localtime_r(&sp_lstchg, &tm);
< strftime(date, sizeof(date), "%Y-%m-%d", &tm);
---
> strftime(date, sizeof(date), "%Y-%m-%d", &sp_lstchg);
Comment 2 Miloslav Trmač 2014-09-22 16:51:48 UTC 
Thanks for your report.

Ultimately, the /etc/shadow field’s granularity of 24 hours is just not precise enough to report the correct password change date.

If we output local time, we are relevant to the user but may be mistaken (because the cutoff happens during the local-time-measured day); if we output UTC, we are precise but irrelevant to users (users don’t measure their days in UTC).  In either case, users in most timezones will see some password change dates as incorrect.

See bug 1019850 for more detailed discussion.

The right thing to do is to replace or augment sp_lstchg with a more precise timestamp, and the sssd team I believe has this in their to-do list.

Before that happens, changing the timezone in the (passwd -S) output would be a breaking change that neither fixes the problem, nor, in my opinion, is a significant enough improvement to warrant the incompatible change in behavior.
Comment 3 James 2014-09-24 19:43:16 UTC 
While I agree that the actual solution is to use a more precise number, I feel that leaving the situation as is confuses those who wish to use the "-S" arguement.

Would you consider having the man page annotated?  It's a benign change that would help others realize why they are not seeing the expected output.
Comment 4 Miloslav Trmač 2014-09-25 13:18:54 UTC 
(In reply to James from comment #3)
> While I agree that the actual solution is to use a more precise number, I
> feel that leaving the situation as is confuses those who wish to use the
> "-S" arguement.
> 
> Would you consider having the man page annotated?  It's a benign change that
> would help others realize why they are not seeing the expected output.

Good idea.  At this point -S is completely undocumented anyway, which is also worth fixing.
Comment 5 Jiri Kucera 2019-01-30 14:54:41 UTC 
Fixed in upstream commit 02d4478318297d24799b03fa53312da5e3f14a40.
https://pagure.io/passwd/c/02d4478318297d24799b03fa53312da5e3f14a40?branch=master
Comment 7 Jan Houska 2019-06-10 16:21:54 UTC 
VERIFIED:

Output of  'man passwd' command:



NEW pass:
passwd-0.79-5.el7.x86_64


       -i, --inactive DAYS
              This will set the number of days which will pass before an expired password for this account will be taken to mean that the account is inactive and should be disabled, if
              the user's account supports password lifetimes.  Available to root only.

       -S, --status
              This will output a short information about the status of the password for a given account. The status information consists of 7 fields. The  first  field  is  the  user's
              login name. The second field indicates if the user account has a locked password (LK), has no password (NP), or has a usable password (PS). The third field gives the date
              of the last password change. The next four fields are the minimum age, maximum age, warning period, and inactivity period for the password. These ages  are  expressed  in
              days.

              Notes: The date of the last password change is stored as a number of days since epoch. Depending on the current time zone, the passwd -S username may show the date of the
              last password change that is different from the real date of the last password change by ±1 day.

              This option is available to root only.

Remember the following two principles
       Protect your password.

OLD FAIL:
passwd-0.79-4.el7.x86_64

       -i, --inactive DAYS
              This will set the number of days which will pass before an expired password for this account will be taken to mean that the account is inactive and should be disabled, if
              the user's account supports password lifetimes.  Available to root only.

       -S, --status
              This will output a short information about the status of the password for a given account. Available to root user only.

Remember the following two principles
       Protect your password.
Comment 9 errata-xmlrpc 2019-08-06 13:11:12 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:2257
Note You need to log in before you can comment on or make changes to this bug.