¿Por qué es "chmod -R 777 /" destructivo?

Esta es una pregunta canónica sobre el permiso de archivos y por qué 777 es "destructivo".

No estoy preguntando cómo solucionar este problema, ya que hay un montón de referencias de eso en Server Fault (reinstalar el SO). ¿Por qué hace algo destructivo en absoluto?

Si alguna vez ha ejecutado este comando, destruirá de inmediato su sistema operativo. No estoy claro por qué eliminar las restricciones tiene algún impacto en los procesos existentes. Por ejemplo, si no tengo acceso de lectura a algo y después de un error de escritura rápido en la terminal, de repente tengo acceso bien ... ¿por qué eso hace que Linux se rompa?

En primer lugar, una pequeña terminología insignificante: chmodno elimina los permisos. Los CAMBIA .

Ahora el meollo del problema - El modo 777significa "Cualquiera puede leer, escribir o ejecutar este archivo" - Usted ha dado permiso para que cualquiera haga (efectivamente) lo que quiera.

Ahora, ¿por qué es esto malo?

1. Acaba de dejar que todos lean / modifiquen cada archivo en su sistema.
   • Adiós a la seguridad de las contraseñas (cualquiera puede leer el archivo oculto y descifrar sus contraseñas, pero ¿por qué molestarse? ¡CAMBIE la contraseña! ¡Es mucho más fácil!).
   • Adiós a la seguridad de sus binarios (alguien puede escribir un nuevo loginprograma que los deje entrar cada vez).
   • Adiós a tus archivos: un usuario dirige mal rm -r /y todo ha terminado. ¡Se le dijo al sistema operativo que les dejara hacer lo que quisieran!
2. Has cabreado todos los programas que verifican los permisos de los archivos antes de comenzar.
   sudo,, sendmaily una gran cantidad de otros simplemente no comenzarán más. Examinarán los permisos de archivos clave, verán que no son lo que se supone que deben ser y devolverán un mensaje de error.
   Del mismo modo, sshse romperá horriblemente (los archivos clave deben tener permisos específicos, de lo contrario son "inseguros" y, por defecto, SSH se negará a usarlos).
3. Has eliminado los bits setuid / setgid en los programas que los tenían.
   El modo 777es en realidad . Entre las cosas en ese dígito principal están los bits y . La mayoría de los programas que son setuid / setgid tienen ese bit establecido porque deben ejecutarse con ciertos privilegios. Están rotos ahora.0777setuidsetgid
   
4. Se ha roto /tmpy/var/tmp la otra cosa en ese dígito octal principal que se puso a cero es el sticky bit- Eso que protege los archivos en /tmp(y /var/tmp) de ser eliminados por personas que no los poseen.
   Hay (desafortunadamente) un montón de scripts de mal comportamiento por ahí que "limpian" haciendo un rm -r /tmp/*, y sin el bit adhesivo establecido /tmp puede despedirse de todos los archivos en ese directorio.
   Tener archivos rascables desaparecer realmente puede alterar algunos programas mal escritos ...
5. Ha causado estragos en /dev /procsistemas de archivos similares y
   esto es más un problema en los sistemas Unix más antiguos donde /devhay un sistema de archivos real, y el contenido que contiene son archivos especiales creados mknod, ya que el cambio de permisos se conservará en los reinicios, pero en cualquier sistema cambiar los permisos de su dispositivo puede causar problemas sustanciales, desde los riesgos de seguridad obvios (todos pueden leer cada TTY) hasta las causas potenciales menos obvias de un pánico en el núcleo.
   Credit to @Tonny for pointing out this possibility
6. Los enchufes y las tuberías pueden romperse, o tener otros problemas. Los enchufes y las tuberías pueden romperse por completo, o estar expuestos a inyecciones maliciosas como resultado de que se puedan escribir en todo el mundo.
   Credit to @Tonny for pointing out this possibility
7. Has hecho que todos los archivos de tu sistema sean ejecutables.
   Mucha gente tiene .en su PATHvariable de entorno (¡no deberías!). Esto podría causar una sorpresa desagradable ya que ahora cualquiera puede soltar un archivo convenientemente llamado como un comando (digamos makeo ls, y intente que ejecute su código malicioso.
   Credit to @RichHomolka for pointing out this possibility
8. En algunos sistemas, chmodse restablecerán las listas de control de acceso (ACL).
   Esto significa que puede terminar teniendo que volver a crear todas sus ACL además de corregir los permisos en todas partes (y es un ejemplo real de que el comando es destructivo).
   Credit to @JamesYoungman for pointing out this possibility

¿Seguirán ejecutándose las partes del sistema que ya se están ejecutando? Probablemente, por un tiempo al menos.
Pero la próxima vez que necesite iniciar un programa, o reiniciar un servicio, o Dios no lo quiera, REINICIE la caja en la que se encuentra en un mundo de dolor, ya que los n. ° 2 y n. ° 3 anteriores alzarán sus feas cabezas.

Una cosa importante es que hay muchas herramientas como ssh / sudo que verifican los permisos del sistema de archivos para los archivos de configuración clave. Si los permisos son incorrectos, estas herramientas están diseñadas para fallar, ya que esto indicaría un serio problema de seguridad. En mi sistema de prueba de Debian y quizás en otros, la capacidad de iniciar sesión falla, probablemente porque el binario de inicio de sesión o algo en PAM tiene verificaciones de permisos.

Por lo tanto, no es realmente que el sistema esté destruido, es que muchas herramientas están diseñadas para fallar inmediatamente cuando los permisos son incorrectos.

Si reinicia un sistema después de hacerlo, chmod 777 -R /se iniciará y podrá iniciar procesos que no tengan comprobaciones explícitas de permisos. Por lo tanto, el sistema no está realmente muerto, solo que, por diseño , es algo inutilizable .