Dlaczego „chmod -R 777 /” jest destrukcyjny?

To jest kanoniczne pytanie dotyczące uprawnień do plików i dlaczego 777 jest „destrukcyjny”.

Nie pytam, jak rozwiązać ten problem, ponieważ istnieje mnóstwo odniesień do tego już w usłudze Server Fault (reinstalacja systemu operacyjnego). Dlaczego w ogóle robi coś destrukcyjnego?

Jeśli kiedykolwiek użyłeś tego polecenia, prawie natychmiast zniszczyłeś swój system operacyjny. Nie jestem pewien, dlaczego usunięcie ograniczeń ma jakikolwiek wpływ na istniejące procesy. Na przykład, jeśli nie mam dostępu do odczytu i po krótkim błędzie w terminalu nagle mam teraz dostęp dobrze ... dlaczego to powoduje uszkodzenie Linuksa?

Przede wszystkim drobna terminologia nitpick: chmodnie usuwa uprawnień. To ZMIANY im.

Teraz sedno problemu - tryb 777oznacza „Każdy może czytać, pisać lub uruchamiać ten plik” - Zezwoliłeś każdemu na (efektywne) wykonywanie, co tylko zechce.

Dlaczego to takie złe?

1. Po prostu pozwalasz wszystkim czytać / modyfikować każdy plik w systemie.
   • Pożegnaj się z bezpieczeństwem haseł na pożegnanie (każdy może odczytać plik cienia i złamać hasło, ale po co zawracać sobie głowę? Po prostu ZMIEŃ hasło! To o wiele łatwiejsze!).
   • Pożegnaj się z bezpieczeństwem dla swoich plików binarnych na pożegnanie (ktoś może po prostu napisać nowy loginprogram, który pozwala im za każdym razem).
   • Pocałuj pliki na pożegnanie: jeden użytkownik przekierowuje rm -r /i to wszystko. OS został poinformowany, aby pozwolił im robić, co chcieli!
2. Wkurzyłeś każdy program, który sprawdza uprawnienia do plików przed uruchomieniem.
   sudo, sendmaili wiele innych po prostu nie będzie już działać. Zbadają kluczowe uprawnienia do plików, zobaczą, że nie są tym, czym powinny być, i wykopią komunikat o błędzie.
   Podobnie sshpsuje się okropnie (pliki kluczy muszą mieć określone uprawnienia, w przeciwnym razie są „niepewne” i domyślnie SSH odmówi ich użycia).
3. Usunąłeś bity setuid / setgid z programów, które je miały.
   Ten tryb 777jest w rzeczywistości . Wśród elementów tej wiodącej cyfry są cyfry i . Większość programów, które są setuid / setgid, mają ustawiony ten bit, ponieważ muszą działać z pewnymi uprawnieniami. Teraz są zepsute.0777setuidsetgid
   
4. Złamałeś /tmpi/var/tmp Inna sprawa, w tym wiodących ósemkowej cyfry, które dostał zero'd jest sticky bit- To, co chroni pliki w /tmp(i /var/tmp) przed usunięciem przez osoby, które nie są ich właścicielami.
   Istnieje (niestety) wiele źle zachowujących się skryptów, które „czyszczą”, wykonując rm -r /tmp/*i bez ustawionego bitu /tmp , możesz pocałować wszystkie pliki w tym katalogu na pożegnanie.
   Zniknięcie plików scratch może naprawdę zdenerwować niektóre źle napisane programy ...
5. Spowodowałeś spustoszenie /dev /proci podobne systemy plików
   Jest to większy problem na starszych systemach Unix, gdzie /devjest prawdziwy system plików, a zawarte w nim elementy to specjalne pliki utworzone za pomocą mknod, ponieważ zmiana uprawnień zostanie zachowana podczas ponownego uruchamiania, ale w dowolnym systemie zmiana uprawnień urządzenia może powodować poważne problemy, od oczywistych zagrożeń bezpieczeństwa (każdy może odczytać każdy TTY) do mniej oczywistych potencjalnych przyczyn paniki jądra.
   Credit to @Tonny for pointing out this possibility
6. Gniazda i rury mogą się zepsuć lub mieć inne problemy. Gniazda i rury mogą ulec całkowitemu pęknięciu lub zostać narażone na złośliwe wstrzyknięcie w wyniku zapisu na całym świecie.
   Credit to @Tonny for pointing out this possibility
7. Sprawiłeś, że każdy plik w systemie jest wykonywalny
   . Wiele osób ma .w swojej PATHzmiennej środowiskowej (nie powinieneś!) - Może to spowodować nieprzyjemną niespodziankę, ponieważ teraz każdy może upuścić plik o dogodnej nazwie jak polecenie (powiedz makelub lsi spróbuj nakłonić Cię do uruchomienia złośliwego kodu.
   Credit to @RichHomolka for pointing out this possibility
8. W niektórych systemach chmodzresetuje listy kontroli dostępu (ACL).
   Oznacza to, że możesz skończyć z koniecznością ponownego utworzenia wszystkich list ACL oprócz ustalania uprawnień wszędzie (i jest to rzeczywisty przykład polecenia niszczącego).
   Credit to @JamesYoungman for pointing out this possibility

Czy działające już części systemu będą nadal działać? Prawdopodobnie przynajmniej przez jakiś czas.
Ale następnym razem, gdy będziesz musiał uruchomić program, zrestartować usługę lub zabraniać nieba, ponownie uruchom skrzynkę, w której czeka cię świat bólu, ponieważ punkty 2 i 3 powyżej odwrócą swoje brzydkie głowy.

Jedną z głównych rzeczy jest to, że istnieje wiele narzędzi, takich jak ssh / sudo, które sprawdzają uprawnienia systemu plików dla kluczowych plików konfiguracyjnych. Jeśli uprawnienia są nieprawidłowe, narzędzia te ulegają awarii, ponieważ oznaczałoby to poważny problem z bezpieczeństwem. W moim systemie testowym Debiana i być może w innych, możliwość logowania się nie udaje, prawdopodobnie dlatego, że binarny login lub coś w PAM ma sprawdzanie uprawnień.

Tak naprawdę nie jest tak, że system jest zniszczony - chodzi o to, że wiele narzędzi zaprojektowano tak, aby natychmiast ulegały awarii, gdy uprawnienia są błędne.

Jeśli zrestartujesz system po chmod 777 -R /jego uruchomieniu, uruchomi się i możesz uruchomić procesy, które nie mają wyraźnych kontroli uprawnień. Tak więc system nie jest tak naprawdę martwy, a jedynie nieco bezużyteczny według projektu .