Warum ist "chmod -R 777 /" destruktiv?

Dies ist eine kanonische Frage zur Dateiberechtigung und warum 777 "destruktiv" ist.

Ich frage nicht, wie man dieses Problem behebt, da es bereits unzählige Verweise auf Server Fault gibt (installieren Sie das Betriebssystem neu). Warum macht es überhaupt etwas zerstörerisches?

Wenn Sie diesen Befehl jemals ausgeführt haben, zerstören Sie Ihr Betriebssystem so ziemlich sofort. Mir ist nicht klar, warum das Entfernen von Einschränkungen Auswirkungen auf vorhandene Prozesse hat. Zum Beispiel, wenn ich keinen Lesezugriff auf etwas habe und nach einem kurzen Tippfehler im Terminal plötzlich Zugriff habe ... warum bricht Linux dadurch zusammen?

Zunächst einmal eine kleinere Terminologie nitpick: chmodnicht entfernen Berechtigungen. Es verändert sie.

Jetzt kommt es auf das Wesentliche an - Der Modus 777bedeutet "Jeder kann diese Datei lesen, schreiben oder ausführen" - Sie haben jedem die Erlaubnis erteilt , (effektiv) zu tun, was immer er will.

Warum ist das so schlimm?

1. Sie lassen einfach alle Dateien auf Ihrem System lesen / ändern.
   • Kiss password security goodbye (jeder kann die Shadow-Datei lesen und Ihre Passwörter knacken, aber warum sich die Mühe machen? Ändern Sie einfach das Passwort! Es ist viel einfacher!).
   • Küssen Sie die Sicherheit für Ihre Binärdateien zum Abschied (jemand kann einfach ein neues loginProgramm schreiben , das ihn jedes Mal einlässt).
   • Küssen Sie Ihre Dateien auf Wiedersehen: Ein Benutzer leitet fehl rm -r /und es ist alles vorbei. Das Betriebssystem wurde angewiesen, sie tun zu lassen, was sie wollten!
2. Sie haben jedes Programm angepisst, das vor dem Start die Berechtigungen für Dateien überprüft.
   sudo,, sendmailund viele andere werden einfach nicht mehr starten. Sie überprüfen die Berechtigungen für Schlüsseldateien, stellen fest, dass sie nicht den Anforderungen entsprechen, die sie erfüllen sollen, und melden sich mit einer Fehlermeldung zurück.
   Ebenso sshwird es fürchterlich kaputt gehen (Schlüsseldateien müssen bestimmte Berechtigungen haben, andernfalls sind sie "unsicher" und SSH wird sie standardmäßig ablehnen.)
3. Sie haben die setuid / setgid-Bits in den Programmen gelöscht, in denen sie vorhanden waren.
   Der Modus 777ist eigentlich . Unter den Dingen in dieser führenden Ziffer befinden sich die und Bits. Die meisten Programme, die setuid / setgid sind, haben dieses Bit gesetzt, weil sie mit bestimmten Berechtigungen ausgeführt werden müssen. Sie sind jetzt kaputt.0777setuidsetgid
   
4. Du bist kaputt /tmpund/var/tmp die andere Sache in dieser führenden Oktal-Ziffer, die Null erreicht hat, ist die sticky bit- die Dateien in /tmp(und /var/tmp) davor schützt , von Leuten gelöscht zu werden, die sie nicht besitzen.
   Es gibt (leider) viele schlecht benommene Skripte, die durch Ausführen eines "aufräumen" rm -r /tmp/*und ohne das festgelegte "Sticky Bit" /tmp können Sie alle Dateien in diesem Verzeichnis zum Abschied küssen.
   Das Verschwinden von Arbeitsdateien kann einige schlecht geschriebene Programme wirklich verärgern ...
5. Sie haben Verwüstungen in /dev /procund ähnlichen Dateisystemen verursacht.
   Dies ist ein größeres Problem in älteren Unix-Systemen, in denen /deves sich um ein echtes Dateisystem handelt, und die Inhalte sind spezielle Dateien, die mit erstellt wurden mknod, da die Berechtigungsänderungen über Neustarts hinweg, jedoch auf jedem System, beibehalten werden Das Ändern der Berechtigungen Ihres Geräts kann erhebliche Probleme verursachen, von offensichtlichen Sicherheitsrisiken (jeder kann jeden TTY lesen) bis hin zu weniger offensichtlichen potenziellen Ursachen für eine Kernel-Panik.
   Credit to @Tonny for pointing out this possibility
6. Sockets und Pipes können brechen oder andere Probleme haben Sockets und Pipes können vollständig brechen oder einer böswilligen Injektion ausgesetzt sein, da sie für die Welt beschreibbar sind.
   Credit to @Tonny for pointing out this possibility
7. Sie haben jede Datei auf Ihrem System ausführbar gemacht.
   Viele Benutzer haben .eine PATHUmgebungsvariable (das sollten Sie nicht!). Dies könnte eine unangenehme Überraschung darstellen, da jetzt jeder eine Datei ablegen kann, die wie ein Befehl benannt ist (sagen Sie makeoder lsund) Versuchen Sie, Sie dazu zu bringen, ihren bösartigen Code auszuführen.
   Credit to @RichHomolka for pointing out this possibility
8. Auf einigen Systemen chmodwerden Zugriffssteuerungslisten (Access Control Lists, ACLs) zurückgesetzt.
   Dies bedeutet, dass Sie möglicherweise alle Ihre ACLs neu erstellen müssen, um Berechtigungen überall zu korrigieren (und ist ein aktuelles Beispiel für einen destruktiven Befehl).
   Credit to @JamesYoungman for pointing out this possibility

Laufen die Teile des Systems, die bereits laufen, weiter? Wahrscheinlich zumindest für eine Weile.
Aber wenn Sie das nächste Mal ein Programm starten oder einen Dienst neu starten müssen, oder wenn der Himmel es verbietet, die Box, in der Sie sich befinden, neu zu starten, besteht Verletzungsgefahr, da # 2 und # 3 oben ihre hässlichen Köpfe aufrichten.

Eine wichtige Sache ist, dass es viele Tools wie ssh / sudo gibt, die die Dateisystemberechtigungen für Schlüsselkonfigurationsdateien prüfen. Wenn die Berechtigungen falsch sind, schlagen diese Tools fehl, da dies auf ein schwerwiegendes Sicherheitsproblem hinweisen würde. Auf meinem Debian-Testsystem und vielleicht auf anderen schlägt die Fähigkeit zur Anmeldung fehl, wahrscheinlich, weil die Anmeldebinärdatei oder etwas in PAM Berechtigungsprüfungen hat.

Es ist also nicht wirklich so, dass das System zerstört wird - es ist so, dass viele Tools so konzipiert sind, dass sie sofort versagen, wenn die Berechtigungen falsch sind.

Wenn Sie ein System nach einem Neustart neu chmod 777 -R /starten, wird es gestartet, und Sie können Prozesse starten, die keine expliziten Berechtigungsprüfungen haben. So ist das System nicht wirklich tot, nur etwas unbrauchbar by-Design .