Perché "chmod -R 777 /" è distruttivo?

Questa è una domanda canonica sull'autorizzazione di file e perché 777 è "distruttiva".

Non sto chiedendo come risolvere questo problema, poiché ci sono molti riferimenti già presenti su Server Fault (reinstallare il sistema operativo). Perché fa qualcosa di distruttivo?

Se hai mai eseguito questo comando, praticamente immediatamente distruggi il tuo sistema operativo. Non sono chiaro perché la rimozione delle restrizioni abbia alcun impatto sui processi esistenti. Ad esempio, se non ho accesso in lettura a qualcosa e dopo un breve errore di digitazione nel terminale, ora ho accesso bene ... perché ciò provoca l'interruzione di Linux?

Prima di tutto un nitpick di terminologia minore: chmodnon rimuove le autorizzazioni. E MODIFICHE loro.

Ora il problema del problema - La modalità 777significa "Chiunque può leggere, scrivere o eseguire questo file" - Hai dato il permesso a chiunque di fare (in modo efficace) qualunque diavolo desiderasse.

Ora, perché è così male?

1. Hai appena permesso a tutti di leggere / modificare tutti i file sul tuo sistema.
   • Bacio addio sicurezza password (chiunque può leggere il file shadow e decifrare le password, ma perché preoccuparsi? Basta cambiare la password! È molto più facile!).
   • Dì addio alla sicurezza per i tuoi file binari (qualcuno può semplicemente scrivere un nuovo loginprogramma che li faccia entrare ogni volta).
   • Addio ai tuoi file: un utente indirizza erroneamente rm -r /ed è tutto finito. Il 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, sendmaile molti altri semplicemente non inizieranno più. Esamineranno le autorizzazioni per i file chiave, vedranno che non sono ciò che dovrebbero essere e rilasceranno un messaggio di errore.
   Allo stesso modo sshsi interromperà in modo orribile (i file chiave devono avere autorizzazioni specifiche, altrimenti sono "non sicuri" e per impostazione predefinita SSH rifiuterà di usarli).
3. Hai cancellato i bit setuid / setgid sui programmi che li avevano.
   La modalità 777è in realtà . Tra le cose in quella cifra iniziale ci sono i bit e . La maggior parte dei programmi che sono setuid / setgid hanno quel bit impostato perché devono essere eseguiti con determinati privilegi. Sono rotti adesso.0777setuidsetgid
   
4. Hai rotto /tmpe/var/tmp L'altra cosa in quella cifra ottale che ha ottenuto zero è la sticky bit- Ciò che protegge i file in /tmp(e /var/tmp) dall'eliminazione di persone che non li possiedono.
   Ci sono (purtroppo) molti script maleducati là fuori che "ripuliscono" facendo un rm -r /tmp/*, e senza il bit appiccicoso impostato /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 provocato il caos in /dev /proce file system simili
   questo è più di un problema su sistemi Unix più vecchi, dove /devè un vero e proprio file system, e la roba che contiene sei file speciali creati con mknod, come la modifica delle autorizzazioni saranno conservati dopo il riavvio, 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 panico nel kernel.
   Credit to @Tonny for pointing out this possibility
6. Prese e tubi possono rompersi o avere altri problemi Prese e tubi possono rompersi del tutto o essere esposti a iniezioni dannose a causa della loro scrittura nel mondo.
   Credit to @Tonny for pointing out this possibility
7. Hai reso eseguibile ogni file sul tuo sistema
   Molte persone hanno .nella loro PATHvariabile d'ambiente (non dovresti!) - Ciò potrebbe causare una spiacevole sorpresa poiché ora chiunque può rilasciare un file comodamente chiamato come un comando (diciamo makeo ls, e prova a farti eseguire il loro codice malevolo.
   Credit to @RichHomolka for pointing out this possibility
8. Su alcuni sistemi chmodripristinerà gli elenchi di controllo degli accessi (ACL).
   Ciò significa che potresti finire per ricreare tutti gli ACL oltre a correggere le autorizzazioni ovunque (ed è un vero esempio del comando 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 devi lanciare un programma, o riavviare un servizio, o il cielo ti proibisce di riavviare la scatola in cui ti trovi per un mondo ferito dato che il n. 2 e il n. 3 sopra aumenteranno le loro brutte teste.

Una cosa importante è che ci sono molti strumenti come ssh / sudo che controllano le autorizzazioni del filesystem per i file di configurazione delle chiavi. Se le autorizzazioni sono errate, questi strumenti sono progettati per fallire, poiché ciò indicherebbe un grave 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 i controlli delle autorizzazioni.

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

Se si riavvia un sistema dopo averlo eseguito chmod 777 -R /, verrà avviato e sarà possibile avviare processi che non dispongono di controlli espliciti delle autorizzazioni. Quindi il sistema non è davvero morto, ma solo in qualche modo inutilizzabile in base alla progettazione .