Wahrscheinlich beide:
Wenn Sie in Ihrer Berechnung das Datum "-u" hinzufügen, würde ich davon ausgehen, dass der 21. Juni ebenfalls zurückgegeben wird.
Mir ist aufgefallen, dass in RHEL 6 "chage -l USER" und "passwd -S USER" unterschiedliche Datumsangaben für das Passwort angeben. Neugierig zu wissen warum. Folgendes sehe ich:
[root@sci-fi ~]# chage -l jedi Last password change : Jun 21, 2015 Password expires : never Password inactive : never Account expires : never Minimum number of days between password change : 0 Maximum number of days between password change : 99999 Number of days of warning before password expires : 7 [root@sci-fi ~]# passwd -S jedi jedi PS 2015-06-20 0 99999 7 -1 (Password set, SHA512 crypt.)
Wenn ich die Ergebnisse mit dem übereinstimme, was in / etc / shadow für das neue Konto angezeigt wird, erhalte ich den 20.06.2015, wie passwd zeigt. Hier ist die Epoche in einen Datumswert für den Benutzer jedi umgewandelt:
[root@sci-fi ~]# date -d@"$(echo "$(awk -F ":" '/jedi/ ' /etc/shadow)*86400"|bc)" Sat Jun 20 20:00:00 EDT 2015
Also, was ist richtig?
** Obwohl die richtige Antwort bereits gegeben wurde. Ich habe noch ein wenig gegraben und konnte beweisen, dass die Antwort richtig ist. Dieser Link war sehr hilfreich:
https://serverfault.com/questions/220633/calculate-days-s-1-1-1970
Ich habe einen Test gemacht, um das zu beweisen. Ich habe ein neues Passwort für den Jedi-Account festgelegt. Die aktuellen Tage seit der Epoche sind 16823, wie unten berechnet
[root@sci-fi ~]# echo $(($(date --utc --date "$1" +%s)/86400)) 16823
Die Datei / etc / shadow stimmt damit überein (dies ist eine Tatsache):
[root@sci-fi ~]# awk -F ":" '/jedi/ ' /etc/shadow 16823
Das strace-Tool zeigt mir an, dass auf die Datei / etc / shadow von chage zugegriffen wird. Ja, einige andere Dateien werden von chage gelesen, aber nur die Shadow-Datei hat die Tage seit der letzten Zeit, als das Passwort zuletzt gesetzt wurde
[root@sci-fi ~]# strace chage -l jedi 2>&1 | grep etc open("/etc/ld.so.cache", O_RDONLY) = 3 access("/etc/shadow", F_OK) = 0 open("/etc/passwd", O_RDONLY) = 4 open("/etc/shadow", O_RDONLY) = 5 open("/etc/localtime", O_RDONLY) = 6
Daher überrascht es nicht, dass das Programm chage berichtet, dass das Passwort zuletzt am 23. Januar geändert wurde
[root@sci-fi ~]# chage -l jedi | head -1 Last password change : Jan 23, 2016
Mit strace sieht es so aus, als würde der Befehl passwd auch die letzte Passwortänderung aus / etc / shadow herausziehen.
[root@sci-fi ~]# strace passwd -S jedi 2>&1 | grep etc open("/etc/ld.so.cache", O_RDONLY) = 3 open("/etc/nsswitch.conf", O_RDONLY) = 4 read(4, "#\n# /etc/nsswitch.conf\n#\n# An ex"..., 4096) = 1688 open("/etc/ld.so.cache", O_RDONLY) = 4 open("/etc/passwd", O_RDONLY|O_CLOEXEC) = 4 open("/etc/passwd", O_RDONLY|O_CLOEXEC) = 4 open("/etc/libuser.conf", O_RDONLY) = 4 open("/etc/login.defs", O_RDONLY) = 4 open("/etc/default/useradd", O_RDONLY) = 4 stat("/etc/shadow", ) = 0 open("/etc/passwd", O_RDONLY) = 4 open("/etc/shadow", O_RDONLY) = 4 open("/etc/localtime", O_RDONLY) = 4
Die Ausgabe "passwd -S" scheint die letzte Kennwortänderungszeit in / etc / shadow in Bezug auf das Gebietsschema des Systems aufzuzeichnen. Hier ist mein Gebietsschema und die Ausgabe von "passwd -S":
[root @ sci-fi ~] # ls -l / etc / localtime lrwxrwxrwx. 1 wurzel wurzel 36 Jan 23 17:59 / etc / localtime -> / usr / share / zoneinfo / America / New_York
[root @ sci-fi ~] # passwd -S jedi jedi PS 2016-01-22 0 99999 7 -1 (Kennwort festgelegt, SHA512-Verschlüsselung.)
Um meine Theorie zu testen. Ich habe die Zone in London geändert (5 Stunden vorher):
[root@sci-fi ~]# ls -l /etc/localtime lrwxrwxrwx. 1 root root 33 Jan 24 00:33 /etc/localtime -> /usr/share/zoneinfo/Europe/London [root@sci-fi ~]# passwd -S jedi jedi PS 2016-01-23 0 99999 7 -1 (Password set, SHA512 crypt.)
Die Ausgabe des Befehls "passwd -S" stimmt jetzt mit dem überein, was von "chage -l" gesehen wird.
Wenn ich stattdessen die Zeitzone in Mountain Standard (MST) umstelle, erhalte ich denselben Wert wie bei der EST-Zeitzone:
[root@sci-fi ~]# ls -l /etc/localtime lrwxrwxrwx. 1 root root 34 Jan 23 17:49 /etc/localtime -> /usr/share/zoneinfo/America/Denver [root@sci-fi ~]# passwd -S jedi jedi PS 2016-01-22 0 99999 7 -1 (Password set, SHA512 crypt.)
Wahrscheinlich beide:
Wenn Sie in Ihrer Berechnung das Datum "-u" hinzufügen, würde ich davon ausgehen, dass der 21. Juni ebenfalls zurückgegeben wird.