Keine Passwort Änderung mehr möglich

[Psych]

Hallo zusammen,

ich musste große Teile eines OpenVZ Containers (Proxmox) über Rsync aus einem Backup wiederherstellen.
Nun kann man sich nicht mehr per SSH einloggen (passwort falsch) und wenn ich versuche das PW zu ändern bekomme ich folgendes:

Code: Alles auswählen

passwd
Enter new UNIX password: 
Retype new UNIX password: 
passwd: Authentication token manipulation error
passwd: password unchanged

Weiß jemand woran das liegt?

Danke.

[syssi]

Schau mal, was sich im auth.log finden laesst. Es sieht danach aus, als ob deine PAM-Konfiguration (/etc/pam.d) kaputt ist oder ein Bestandteile (Libs) von PAM fehlen, die bei der Authentifizierung genutzt werden.

[uname]

Du könntest mal versuchen passwd mit strace aufzurufen.

Code: Alles auswählen

strace passwd

[Psych]

Strace gibt am Ende folgendes aus:

Code: Alles auswählen

open("/etc/.pwd.lock", O_WRONLY|O_CREAT|O_CLOEXEC, 0600) = -1 EACCES (Permission denied)
nanosleep({0, 1000000}, NULL)           = 0
open("/etc/.pwd.lock", O_WRONLY|O_CREAT|O_CLOEXEC, 0600) = -1 EACCES (Permission denied)
nanosleep({0, 1000000}, NULL)           = 0
open("/etc/.pwd.lock", O_WRONLY|O_CREAT|O_CLOEXEC, 0600) = -1 EACCES (Permission denied)

Und in der Auth.log findet sich das hier:

Code: Alles auswählen

Feb 25 16:46:11 arabic2 unix_chkpwd[8697]: check pass; user unknown
Feb 25 16:46:11 arabic2 unix_chkpwd[8698]: could not obtain user info (root)

[syssi]

Wie sieht denn deine /etc/passwd aus?

[Psych]

Wie sieht denn deine /etc/passwd aus?

Nicht ungewöhnlich würde ich behaupten...

Code: Alles auswählen

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/bin/sh
man:x:6:12:man:/var/cache/man:/bin/sh
lp:x:7:7:lp:/var/spool/lpd:/bin/sh
mail:x:8:8:mail:/var/mail:/bin/sh
news:x:9:9:news:/var/spool/news:/bin/sh
uucp:x:10:10:uucp:/var/spool/uucp:/bin/sh
proxy:x:13:13:proxy:/bin:/bin/sh
www-data:x:33:33:www-data:/var/www:/bin/sh
backup:x:34:34:backup:/var/backups:/bin/sh
list:x:38:38:Mailing List Manager:/var/list:/bin/sh
irc:x:39:39:ircd:/var/run/ircd:/bin/sh
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/bin/sh
nobody:x:65534:65534:nobody:/nonexistent:/bin/sh
libuuid:x:100:101::/var/lib/libuuid:/bin/sh
smmta:x:101:103:Mail Transfer Agent,,,:/var/lib/sendmail:/bin/false
smmsp:x:102:104:Mail Submission Program,,,:/var/lib/sendmail:/bin/false
bind:x:103:107::/var/cache/bind:/bin/false
fetchmail:x:104:65534::/var/lib/fetchmail:/bin/false
sshd:x:105:65534::/var/run/sshd:/usr/sbin/nologin
mysql:x:106:110:MySQL Server,,,:/var/lib/mysql:/bin/false
...
...

[uname]

Vielleicht kann "root" aus irgendwelchen Gründen nicht in /etc schreiben. Auch könntest du mal schauen wie /etc/pam.d/passwd aussieht. Vielleicht kannst du auch das Paket passwd neu installieren. Wobei dann müsstest du eigentlich vorher auch alle abhängigen Bibliotheken mal neu installieren.

[Cae]

Wenn lokales Einloggen geht, SSH aber nicht, wuerde ich zuerst die /etc/ssh/sshd_config angucken (Stichwort PermitRootLogin). Danach die PAM-Konfiguration, die den SSH-Teil betrifft, als /etc/pam.d/sshd und von dort inkludierte.

Gruss Cae

[Psych]

Root kann problemlos in /etc schreiben.

Einloggen über SSH geht nicht, muss aber nix mit SSH zu tun haben.
Es handelt sich um einen OpenVZ Container, in den ich mich aus dem Host System heraus über vzctl enter "eingeloggt" habe.

[Cae]

Klappt dann ein

Code: Alles auswählen

# su -l {irgendwer}
$ su -

? Also erst zu einem unprivilegierten User werden und dann zurueck zu root, welches Anmeldedaten erfordert.

Gruss Cae

[Psych]

Klappt dann ein

Code: Alles auswählen

# su -l {irgendwer}
$ su -

? Also erst zu einem unprivilegierten User werden und dann zurueck zu root, welches Anmeldedaten erfordert.

Gruss Cae

Ich krieg beim Wechsel zu einem unprivilegiertem Nutzer sofort:

Code: Alles auswählen

su: Authentication failure
(Ignored)
setgid: Operation not permitted

[wanne]

Code: Alles auswählen

su: Authentication failure
(Ignored)
setgid: Operation not permitted

Ohne jetzt wirklich Ahnung zu haben sieht das für mich ganz extrem nachen nem OpenVZ spezifischen Fehler aus. Das Ding war mir aber schon immer unheimlich.

[Psych]

Code: Alles auswählen

su: Authentication failure
(Ignored)
setgid: Operation not permitted

Ohne jetzt wirklich Ahnung zu haben sieht das für mich ganz extrem nachen nem OpenVZ spezifischen Fehler aus. Das Ding war mir aber schon immer unheimlich.

Ich bin recht sicher, dass es nix mit OpenVZ zu tun hat.
Aus irgendeinem Grund hat der beim wiedereinspielen des Backups Dateirechte verloren und bestimmte Dateien kaputt gemacht.
Ich habe insgesamt 3 Container aus dem Backup wiederhergestellt. Einer hat gar keine Probleme gemacht, beim zweiten musste ich ein paar Rechte neu setzen und der dritte hat jede Menge Rechte zerschossen, und dieses Auth Problem.

[wanne]

Dateirechte verloren

Ah, das könnte das auch erklären. setgid darf nur root ausführen.
Authentication failure gib's wenn der Nutzer die /etc/passwd oder /etc/shadow nicht lesen darf.
Ich tippe mal auf ein fehldendes suid bit an su.
Kanst du mal folgendes posten:

Code: Alles auswählen

ls -ld /bin/su /etc /etc/passwd /etc/shadow
cat /proc/self/loginuid

[Cae]

Stammt die /etc/passwd ebenfalls wieder aus dem Backup? Ich hab' da gerade so eine Idee, es koennte das UID/Name-Mapping verkehrt sein. 'Ne Moeglichkeit waere natuerlich auch ein fehlendes SetUID-Bit auf der /bin/su oder etwas in der Richtung.

Gruss Cae

[syssi]

Stammt die /etc/passwd ebenfalls wieder aus dem Backup? Ich hab' da gerade so eine Idee, es koennte das UID/Name-Mapping verkehrt sein. 'Ne Moeglichkeit waere natuerlich auch ein fehlendes SetUID-Bit auf der /bin/su oder etwas in der Richtung.

Den Verdacht habe ich auch. Entweder findet schon beim Backup-Lauf ein mapping statt oder beim zurueckspielen wurde vergessen das Name-Mapping zu deaktivieren. Bei Systemen, welche dem Backup-Server sehr sehr aehnlich sind gibt es keine Probleme. Bei Systemen, bei welchen die UIDs in einer anderen Reihenfolge verteilt wurden kracht es nun.

[Psych]

Stammt die /etc/passwd ebenfalls wieder aus dem Backup? Ich hab' da gerade so eine Idee, es koennte das UID/Name-Mapping verkehrt sein. 'Ne Moeglichkeit waere natuerlich auch ein fehlendes SetUID-Bit auf der /bin/su oder etwas in der Richtung.

Den Verdacht habe ich auch. Entweder findet schon beim Backup-Lauf ein mapping statt oder beim zurueckspielen wurde vergessen das Name-Mapping zu deaktivieren. Bei Systemen, welche dem Backup-Server sehr sehr aehnlich sind gibt es keine Probleme. Bei Systemen, bei welchen die UIDs in einer anderen Reihenfolge verteilt wurden kracht es nun.

Alle Dateien stammen aus dem Backup:

Code: Alles auswählen

ls -ld /bin/su /etc /etc/passwd /etc/shadow
-rwsr-xr-x  1 smmta staff  29152 Feb 15  2011 /bin/su
drwxr-xr-x 80 root  root    4096 Feb 27 23:03 /etc
-rw-r--r--  1 root  root    3432 Feb 20 17:33 /etc/passwd
-rw-r-----  1 root  shadow  7106 Feb 20 17:33 /etc/shadow

Ich hab "chown root:root /bin/su" ausgeführt und... siehe da: su funktioniert wieder.
Was noch nicht geht ist sudo:

Code: Alles auswählen

sudo -s
sudo: must be setuid root

 ls -l /usr/bin/sudo
-rwxr-xr-x 2 root root 144740 May 23  2012 /usr/bin/sudo

Was fehlt da wohl noch?

Vielen Dank soweit schon mal

[syssi]

So sollte es aussehen:

Code: Alles auswählen

$ ls -l /usr/bin/sudo
-rwsr-xr-x 2 root root 116920 Jun 28  2012 /usr/bin/sudo
$ 

Dir fehlt das S-Bit.

[Cae]

Deine suid-Bits sind kaputt:

Code: Alles auswählen

$ ls -l $(which sudo)
-rwsr-xr-x 2 root root 116920 Jun 28  2012 /usr/bin/sudo
   * <--

Code: Alles auswählen

-rwxr-xr-x 2 root root 144740 May 23  2012 /usr/bin/sudo

Guck' nochmal in der History nach, mit welcher Zeile das Backup wieder zurueckgespielt wurde.

Gruss Cae

[Psych]

Vielen Dank. Nun geht (glaube ich) alles wieder.

Damit sowas nicht noch mal passiert:

Wie kann ich mit rsync ein Backup so erstellen und zurückspielen, dass keine Rechte verloren gehen?

[syssi]

Der Trick ist beim Backup und beim zurueckspielen das dynamische Mapping zu unterbinden ("--numeric-ids") zusammen mit dem normalen Parameter ("-a"), den du vermutlich schon benutzt. In deinem Backup solltest du einmal pruefen, ob auch das "suid bit" mit gesynct wird. Ich bin mir da nicht so sicher.

[Cae]

In deinem Backup solltest du einmal pruefen, ob auch das "suid bit" mit gesynct wird. Ich bin mir da nicht so sicher.

Ja, in dieser Richtung wuerde ich auch forschen.

Weitere Ideen: Was passiert beim Backup, wenn das Zielsystem kein SUID kennt? Geht verloren, vermute ich mal. Wenn's nosuid gemountet ist? Sollte erhalten bleiben, aber halt ohne Funktion. Falls auf NFS oder sowas gebackupt wird, da koennte ich mir vorstellen, dass der Server das Bit bei entsprechender Einstellung komplett killt.

Gruss Cae

[Psych]

--numeric-ids hat bei dem Server mit den defekten Rechten gefehlt .

Ich sichere meistens über rsync auf ein ZFS (openindiana) System.

Danke nochmal.