"Passwort wechsel dich" mit FreeBSD

Eine regelmäßiger Passwortwechsel ist bei mir üblich, nur klappte er dieses Mal nicht. Seit einer Woche gelingt es mir nicht, mich mit dem neuen Passwort anzumelden. Es ist und bleibt beim alten Passwort.

Störungen in der Normalität

Ein Passwortwechsel ist einfach. Man ruf als Nutzer das Kommando passwd auf.

[lutz@thunder ~]$ passwd 
Changing local password for lutz
Old Password: AltesPassword
New Password: NeuesPassword
Retype New Password: NeuesPassword
Password changed.

Soweit so erinfach. Nur ein Problem gibt es: Es funktioniert nicht.

Alle weiteren Anmeldungen werden ausschließlich mit dem alten Password befriedigt. Am einfachsten sieht man das, indem man passwd nochmal aufruft.

[lutz@thunder ~]$ passwd 
Changing local password for lutz
Old Password: NeuesPassword
passwd: sorry

Auch Reboot hilft nicht. Die betreffenden Dateien in /etc/ werden aber aktualisiert:

-rw-------  1 root  wheel      2657 11 Mai  10:43 master.passwd
-rw-r--r--  1 root  wheel     40960 11 Mai  10:43 pwd.db
-rw-------  1 root  wheel     40960 11 Mai  10:43 spwd.db
-rw-r--r--  1 root  wheel      2266 11 Mai  10:43 passwd

Auch der Versuch, von root aus das Nutzerpassword zu überschreiben zeigt keinen ernsthaften Erfolg. Zwar ändern sich die Einträge in der master.passwd, und auch der Inhalt der *pwd.db zeigt binäre Modifikationen. Die Authentisierung bleibt jedoch beim alten Password.

Fehlersuche

Auf welche Daten greift eigentlich passwd zurück? Wo holt der die alten Passworte wieder raus?

[lutz@thunder ~]$ truss -o login.log -f -a passwd
Changing local password for lutz
Old Password: NeuesPassword
passwd: sorry
[lutz@thunder ~]$ grep open login.log 
  802: openat(AT_FDCWD,"/etc/libmap.conf",O_CLOEXEC,00) = 3 (0x3)
  802: open("/usr/local/etc/libmap.d",O_NONBLOCK|O_DIRECTORY|O_CLOEXEC,0165) = 3 (0x3)
  802: openat(AT_FDCWD,"/var/run/ld-elf.so.hints",O_CLOEXEC,00) = 3 (0x3)
  802: openat(AT_FDCWD,"/usr/lib/libpam.so.6",O_CLOEXEC|O_VERIFY,00) = 3 (0x3)
  802: openat(AT_FDCWD,"/lib/libc.so.7",O_CLOEXEC|O_VERIFY,00) = 3 (0x3)
  802: open("/etc/nsswitch.conf",O_CLOEXEC,0666) = 3 (0x3)
  802: open("/etc/pwd.db",O_CLOEXEC,00)          = 3 (0x3)
  802: open("/etc/pam.d/passwd",O_RDONLY,0666)   = 3 (0x3)
  802: openat(AT_FDCWD,"/usr/lib/pam_unix.so.6",O_RDONLY,00) = 4 (0x4)
  802: openat(AT_FDCWD,"/lib/libutil.so.9",O_CLOEXEC|O_VERIFY,00) = 5 (0x5)
  802: openat(AT_FDCWD,"/lib/libcrypt.so.5",O_CLOEXEC|O_VERIFY,00) = 5 (0x5)
  802: openat(AT_FDCWD,"/usr/lib/libypclnt.so.4",O_CLOEXEC|O_VERIFY,00) = 5 (0x5)
  802: open("/etc/pam.d/other",O_RDONLY,0666)    = 3 (0x3)
  802: openat(AT_FDCWD,"/usr/lib/pam_opie.so.6",O_RDONLY,00) = 4 (0x4)
  802: openat(AT_FDCWD,"/usr/lib/libopie.so.8",O_CLOEXEC|O_VERIFY,00) = 5 (0x5)
  802: openat(AT_FDCWD,"/lib/libmd.so.6",O_CLOEXEC|O_VERIFY,00) = 5 (0x5)
  802: openat(AT_FDCWD,"/usr/lib/pam_opieaccess.so.6",O_RDONLY,00) = 4 (0x4)
  802: openat(AT_FDCWD,"/usr/lib/pam_unix.so.6",O_RDONLY,00) = 4 (0x4)
  802: open("/etc/pam.d/other",O_RDONLY,0666)    = 3 (0x3)
  802: openat(AT_FDCWD,"/usr/lib/pam_nologin.so.6",O_RDONLY,00) = 4 (0x4)
  802: openat(AT_FDCWD,"/usr/lib/pam_login_access.so.6",O_RDONLY,00) = 4 (0x4)
  802: openat(AT_FDCWD,"/usr/lib/pam_unix.so.6",O_RDONLY,00) = 4 (0x4)
  802: open("/etc/pam.d/other",O_RDONLY,0666)    = 3 (0x3)
  802: openat(AT_FDCWD,"/usr/lib/pam_permit.so.6",O_RDONLY,00) = 4 (0x4)
  802: open("/etc/pwd.db",O_CLOEXEC,00)          = 3 (0x3)

Man sieht sehr schön den gesamten PAM Ablauf, also nichts überraschendes. Die relevanten Datei ist offenbar ausschließlich /etc/pwd.db.

Eine Neuerzeugung mittels pwd_mkdb bringt ebenfalls keine Änderung. Das ist allerdings schon überraschend.

Beim Durchsuchen der Binärdatei mittels strings zeigt sich, dass die Datei inzwischen viele Kopien der Datensätze enthält. Vielleicht ist das ja die Ursache? Es könnte ja sein, dass auf den falschen Datensatz zurückgegriffen wird. Evtl. sind die Einträge auch mehrfach vorhanden?

Als letzten Test will ich sicher gehen, dass wirklich auf einen falschen Datensatz zurückgegriffen wird. Dazu ersetze ich den Passwordteil mit vipw durch einen *. Der Nutzer bekommt also gar kein Password mehr.

[root@thunder /home/lutz]# fgrep lutz /etc/passwd 
lutz:*:1001:1001:Lutz Donnerhacke,,561:/home/lutz:/usr/local/bin/bash
[root@thunder /home/lutz]# fgrep lutz /etc/master.passwd 
lutz:*:1001:1001::0:0:Lutz Donnerhacke,,561:/home/lutz:/usr/local/bin/bash

Anschließend vergebe ich ein neues Passwort als root:

[root@thunder /home/lutz]# passwd lutz
Changing local password for lutz
New Password: NeuesPassword
Retype New Password: NeuesPassword

Und siehe da, es funktioniert!

Sollte das demnächst wieder auftreten, so werden ich für diese Version einen Bugreport schreiben.

[lutz@thunder ~]$ uname -a
FreeBSD thunder 11.0-RELEASE-p9 FreeBSD 11.0-RELEASE-p9 #0: Tue Apr 11 08:48:40 UTC 2017
     root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64

Post a comment

Related content