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

Solución 1:

En primer lugar, una terminología menor:chmod no elimina permisos CAMBIA a ellos.

Ahora el meollo del asunto:el modo 777 significa "Cualquiera puede leer, escribir o ejecutar este archivo" - Tienes concedido permiso para que cualquiera pueda hacer (efectivamente) lo que le dé la gana.

Ahora, ¿por qué es esto malo?

1. Has dejado que todos lean o modifiquen todos los archivos de tu sistema.
   • Dile adiós a la seguridad de las contraseñas (cualquiera puede leer el archivo oculto y descifrar tus contraseñas, pero ¿por qué molestarse? ¡Simplemente CAMBIA la contraseña! ¡Es mucho más fácil!).
   • Dile adiós a la seguridad de tus archivos binarios (alguien puede simplemente escribir un nuevo login programa que les permite entrar cada vez).
   • Dale un beso de despedida a tus archivos:un usuario desvía rm -r / y se acabó ¡Se le dijo al sistema operativo que les permitiera hacer lo que quisieran!
2. Has cabreado a todos los programas que comprueban los permisos de los archivos antes de empezar.
   sudo , sendmail , y 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 ssh se romperá horriblemente (los archivos clave deben tener permisos específicos, de lo contrario, son "inseguros" y, de forma predeterminada, SSH se negará a usarlos).
3. Has borrado los bits setuid/setgid de los programas que los tenían.
   El modo 777 en realidad es 0 777 . Entre las cosas en ese primer dígito están el setuid y setgid pedacitos
   La mayoría de los programas que son setuid/setgid tienen ese bit establecido porque deben ejecutarse con ciertos privilegios. Ahora están rotos.
4. Has roto /tmp y /var/tmp La otra cosa en ese dígito octal inicial que se puso a cero es el sticky bit -- Lo que protege archivos en /tmp (y /var/tmp ) de ser borrados por personas que no los poseen.
   Hay (desafortunadamente) muchos scripts que se comportan mal y que "limpian" haciendo un rm -r /tmp/* , y sin el sticky bit establecido en /tmp puedes despedirte de todos los archivos en ese directorio.
   Hacer que desaparezcan los archivos borradores realmente puede alterar algunos programas mal escritos...
5. Has causado estragos en /dev /proc y sistemas de archivos similares
   Esto es más un problema en los sistemas Unix más antiguos donde /dev es un sistema de archivos real, y lo que contiene son archivos especiales creados con mknod , ya que el cambio de permisos se conservará durante los reinicios, pero en cualquier sistema que cambie 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 kernel panic.
   Credit to @Tonny for pointing out this possibility
6. Los enchufes y las tuberías pueden romperse o tener otros problemas Los zócalos y las tuberías pueden romperse por completo o quedar expuestos a una inyección maliciosa como resultado de su capacidad de escritura mundial.
   Credit to @Tonny for pointing out this possibility
7. Ha convertido todos los archivos de su sistema en ejecutables
   Mucha gente tiene . en su PATH variable de entorno (¡no debería!):esto podría causar una sorpresa desagradable, ya que ahora cualquiera puede soltar un archivo con el nombre conveniente de un comando (digamos make o ls , y tener la oportunidad de hacer que ejecutes su código malicioso.
   Credit to @RichHomolka for pointing out this possibility
8. En algunos sistemas chmod restablecerá 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 funcionando las partes del sistema que ya están funcionando? 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 REINICIAR la caja en la que se encuentra, un mundo de dolor, ya que el n. ° 2 y el n. ° 3 anteriores asomarán sus feas cabezas.

Solución 2:

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 problema de seguridad grave. En mi sistema de prueba 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.

Así que 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 hacer un chmod 777 -R / se iniciará y podrá iniciar procesos que no tengan controles de permisos explícitos. Entonces, el sistema no está realmente muerto, solo algo inutilizable por diseño .