Heute wollte ein Arbeitskollege zusätzliche Schreib- und Leserechte auf alle Dateien in einem Homeverzeichnis vergeben. Mir ist immer noch nicht klar, warum der Besitzer des Homeverzeichnisses einen Symlink auf / hatte, der Effekt war aber natürlich spannend. An dieser Stelle sei erwähnt, dass die Rechte rekursiv angepasst werden sollten.
Angefangen hat es damit, dass andere Benutzer sich nicht mehr per ssh (mit Keyfile-Authentifizierung) einloggen konnten. Sudo ging auch nicht mehr. Wie gut, dass wir das root-Kennwort kennen!
Zur Erläuterung für die, die es nicht wissen: Die Anpassung der Rechte folgte dem Symlink und hat somit zusätzliche Rechte auf alle Dateien/Verzeichnisse des Servers vergeben. Sicherheitskritische Funktionen prüfen oft, ob nicht zu viele Rechte vergeben sind und verweigern die Ausführung. ssh prüft bei der Authentifizierung per Keyfile beispielsweise die rechte der Datei ~/.ssh/authorized_keys. Kann hier jeder ändern, wird die Datei nicht mehr berücksichtigt, ein Login per Keyfile ist also nicht mehr möglich. Ähnlich verhält es sich bei der Datei /etc/sudoers.
In solchen Situationen lobt man sich ein Backup. Nur wollten wir nicht den ganzen Stand des Servers zurückspielen. Deshalb haben wir im Backup die Dateirechte ausgelesen und auf den Server zurück gespielt:
find . -exec stat -c "%a %n" {} \;|while read mod file;do file=${file##.};echo "chmod $mod $file" >>chmod.sh;done;ssh $server sh - <chmod.sh
Damit wurden zumindest alle Dateien, die im Backup vorhanden waren, wieder auf die ursprünglichen Rechte zurück gesetzt.
