 |
Not confirmed. Works just fine here: [root@riana ~]# ls -l /etc/shadow ----------. 1 root root 939 Sep 17 15:22 /etc/shadow [root@riana ~]# passwd -S riana riana PS 2014-09-17 0 180 30 -1 (Password set, SHA512 crypt.) the user was created a couple of hours ago. On a different system: [wolfy@wolfy ~]$ passwd wolfy Changing password for user wolfy. New password: Retype new password: passwd: all authentication tokens updated successfully. [wolfy@wolfy ~]$ sudo passwd -S wolfy wolfy PS 2014-09-17 0 99999 7 -1 (Password set, MD5 crypt.) [wolfy@wolfy ~]$ date Wed Sep 17 16:49:45 EEST 2014 Everything looks just fine here. Are you sure you are not impacted by a TZ difference ? |
|
|
Could be a TZ issue. I am America/New_York. I have symlinked /usr/share/zoneinfo/Americas/New_York to /etc/localtime. |
 |
Don't symlink /etc/localtime as it causes problems. Undo the symlink and cp the file to /etc/localtime. Then run rpm -V tzdata and if it reports any files are mismatched then yum reinstall tzdata and recheck. |
 |
Using symlink is the default setup in el7, it seems. On my RHEL7 system: $ ll /etc/localtime lrwxrwxrwx. 1 root root 41 Aug 12 16:23 /etc/localtime -> ../usr/share/zoneinfo/America/Los_Angeles $ rpm -qf /etc/localtime systemd-208-11.el7_0.2.x86_64 |
|
|
On a CentOS 6.5 X86_64. Following TrevorH suggestion. I ran rpm -V tzdata and it produced no errors. For kicks I copied /usr/share/zoneinfo/Americas/New_York to /etc/localtime and reinstalled tzdata. No change [root@cyclops ~]# date Thu Sep 18 10:57:26 EDT 2014 [root@cyclops ~]# useradd -u 555 -c "Jason P" Jason_P [root@cyclops ~]# ls -ltr /etc/shadow ----------. 1 root root 1223 Sep 18 10:57 /etc/shadow [root@cyclops ~]# passwd -S Jason_P Jason_P LK 2014-09-17 0 99999 7 -1 (Password locked.) [root@cyclops ~]# passwd Jason_P Changing password for user Jason_P. New password: Retype new password: passwd: all authentication tokens updated successfully. [root@cyclops ~]# passwd -S Jason_P Jason_P PS 2014-09-17 0 99999 7 -1 (Password set, SHA512 crypt.) |
|
|
[root@wolfy ~]# useradd -u 555 -c "Jason P" Jason_P [root@wolfy ~]# ls -ltr /etc/shadow ----------. 1 root root 1058 Sep 18 18:17 /etc/shadow [root@wolfy ~]# passwd -S Jason_P Jason_P LK 2014-09-18 0 99999 7 -1 (Password locked.) [root@wolfy ~]# passwd Jason_P Changing password for user Jason_P. New password: BAD PASSWORD: it is WAY too short BAD PASSWORD: is a palindrome Retype new password: passwd: all authentication tokens updated successfully. [root@wolfy ~]# passwd -S Jason_P Jason_P PS 2014-09-18 0 99999 7 -1 (Password set, MD5 crypt.) [root@wolfy ~]# rpkm -q ^C [root@wolfy ~]# rpm -q centos-release centos-release-6-5.el6.centos.11.2.x86_64 [root@wolfy ~]# date Thu Sep 18 18:19:43 EEST 2014 |
|
|
I believe that wolfy doesn't see the bug because wolfy is in a GMT+ zone. The issue arises because /etc/shadow stores the value in days and not seconds (hours would work too) since the Epoch and in GMT. For example, my value /etc/shadow time entry is 16331 days which is 1410998400 seconds. This reads as midnight of September 18, 2014. Wolfy's timezone adds 3 hours and so his month, day and year stays the same. However, Jason_P's timezone is minus 4 so it outputs the previous day. What I see: [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.) Suggested fix in passwd source: 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); |
- Anonymous
