Perché chmod -R 777 / è distruttivo?

Soluzione 1:

Prima di tutto un piccolo pignolo terminologico:chmod non rimuove autorizzazioni. CAMBIA loro.

Ora il nocciolo della questione -- La modalità 777 significa "Chiunque può leggere, scrivere o eseguire questo file" - Hai concesso il permesso che chiunque faccia (efficacemente) quello che vuole.

Ora, perché va male?

1. Hai appena permesso a tutti di leggere/modificare ogni file sul tuo sistema.
   • Bacia addio alla sicurezza della password (chiunque può leggere il file shadow e decifrare le tue password, ma perché preoccuparsi? CAMBIA semplicemente la password! È molto più facile!).
   • Bacia la sicurezza per i tuoi file binari addio (qualcuno può semplicemente scrivere un nuovo login programma che li fa entrare ogni volta).
   • Dice addio ai tuoi file:un utente indirizza erroneamente rm -r / ed è tutto finito. Al sistema operativo è stato detto di lasciarli fare quello che volevano!
2. Hai fatto incazzare ogni programma che controlla le autorizzazioni sui file prima di iniziare.
   sudo , sendmail , e una miriade di altri semplicemente non si avvierà più. Esamineranno i permessi dei file chiave, vedranno che non sono quello che dovrebbero essere e respingono un messaggio di errore.
   Allo stesso modo ssh si romperà in modo orribile (i file chiave devono avere permessi specifici, altrimenti sono "insicuri" e per impostazione predefinita SSH si rifiuterà di usarli.)
3. Hai cancellato i bit setuid/setgid sui programmi che li avevano.
   La modalità 777 in realtà è 0 777 . Tra le cose in quella cifra iniziale c'è il setuid e setgid bit.
   La maggior parte dei programmi setuid/setgid hanno quel bit impostato perché devono essere eseguiti con determinati privilegi. Adesso sono rotti.
4. Hai superato /tmp e /var/tmp L'altra cosa in quella cifra ottale iniziale che ha ottenuto lo zero è il sticky bit -- Quello che protegge i file in /tmp (e /var/tmp ) dall'essere eliminati da persone che non li possiedono.
   Ci sono (sfortunatamente) un sacco di script che si comportano male che "ripuliscono" eseguendo un rm -r /tmp/* , e senza lo sticky bit impostato su /tmp puoi dire addio a tutti i file in quella directory.
   La scomparsa dei file scratch può davvero sconvolgere alcuni programmi scritti male...
5. Hai causato scompiglio in /dev /proc e filesystem simili
   Questo è più un problema sui vecchi sistemi Unix in cui /dev è un vero filesystem, e le cose che contiene sono file speciali creati con mknod , poiché la modifica delle autorizzazioni verrà preservata durante i riavvii, ma su qualsiasi sistema la modifica delle autorizzazioni del dispositivo può causare problemi sostanziali, dagli ovvi rischi per la sicurezza (tutti possono leggere ogni TTY) alle potenziali cause meno ovvie di un kernel panic.
   Credit to @Tonny for pointing out this possibility
6. Prese e tubi potrebbero rompersi o avere altri problemi Socket e pipe possono rompersi completamente o essere esposti a iniezioni dannose a causa della possibilità di essere resi scrivibili in tutto il mondo.
   Credit to @Tonny for pointing out this possibility
7. Hai reso eseguibile ogni file sul tuo sistema
   Molte persone hanno . nel loro PATH variabile d'ambiente (non dovresti!) - Questo potrebbe causare una spiacevole sorpresa poiché ora chiunque può eliminare un file opportunamente chiamato come un comando (ad esempio make o ls e provare a farti eseguire il loro codice dannoso.
   Credit to @RichHomolka for pointing out this possibility
8. Su alcuni sistemi chmod ripristinerà gli elenchi di controllo degli accessi (ACL)
   Ciò significa che potresti finire per dover ricreare tutti i tuoi ACL oltre a correggere le autorizzazioni ovunque (ed è un vero esempio del fatto che il comando sia distruttivo).
   Credit to @JamesYoungman for pointing out this possibility

Le parti del sistema che sono già in esecuzione continueranno a funzionare? Probabilmente, almeno per un po'.
Ma la prossima volta che avrai bisogno di avviare un programma, o riavviare un servizio, o il cielo non voglia REBOOT la scatola in cui ti trovi per un mondo di dolore dato che i punti 2 e 3 sopra alzeranno le loro brutte teste.

Soluzione 2:

Una cosa importante è che ci sono molti strumenti come ssh/sudo che controllano le autorizzazioni del filesystem per i file di configurazione chiave. Se le autorizzazioni sono sbagliate, questi strumenti sono progettati per fallire, in quanto ciò indicherebbe un serio problema di sicurezza. Sul mio sistema di test Debian e forse su altri, la possibilità di accedere non riesce, probabilmente perché il binario di accesso o qualcosa in PAM ha controlli di autorizzazione.

Quindi non è davvero che il sistema viene distrutto, è che molti strumenti sono progettati per fallire immediatamente quando le autorizzazioni sono sbagliate.

Se riavvii un sistema dopo aver eseguito un chmod 777 -R / si avvierà e potrai avviare processi che non hanno controlli di autorizzazione espliciti. Quindi il sistema non è veramente morto, solo un po' inutilizzabile by-design .