¿Por qué chmod 777 -R / deja el sistema inutilizable?
52
Solo estoy otorgando permiso a todos para hacer algo, pero ¿por qué el sistema falla al dar solo permisos? Solo estoy modificando el permiso para no cambiar los archivos.
Creo que no se bloquea, sino que simplemente se cancela el proceso de arranque en algún momento. Si lo miraras /var/log/syslog, incluso descubrirías la razón.
Hola Angel
77
Es importante saber que incluso si esto no rompiera las cosas, no "otorgaría permiso a todos para hacer nada". Todavía habría una gran cantidad de acciones que solo la "raíz" (más precisamente, un proceso con UID cero efectivo) podría hacer.
zwol
66
@Glen si por "relacionado", quiere decir "duplicado exacto que muestra por qué deberíamos ser capaces de marcar como engañados en todos los sitios", ¡entonces seguro! gran enlace ;)
underscore_d
44
Realmente ME ENCANTARÍA saber que la historia sobre usted llegó a hacer esta pregunta.
Dewi Morgan
Respuestas:
104
Hay un par de razones.
Primero, además de los permisos habituales de lectura / escritura / ejecución, hay otros bits que contienen los permisos de archivo. Lo más notable setuidy setgid. Cuando se ejecuta un programa con uno de estos bits de permiso, se obtiene el "UID efectivo" y / o el "GID efectivo" del propietario del programa en lugar del usuario que lo ejecutó. Esto permite que los programas se ejecuten con más permisos que el usuario que los ejecutó. Es utilizado por muchas utilidades cruciales del sistema, incluidos suy sudo. Su chmodcomando borra estos bits dejando las utilidades inutilizables.
En segundo lugar, algunos programas (en particular ssh) realizan una comprobación de validez de los permisos de los archivos y se niegan a usar archivos con permisos que consideran inseguros. Esto reduce el riesgo de que administradores descuidados abandonen accidentalmente agujeros de seguridad, pero hace que lidiar con los permisos de archivos eliminados sea aún más doloroso.
El sistema Linux requiere permisos específicos para ciertos programas como sudo, etc.
Cuando ejecutas chmod 777 -R /, borras todos los permisos y los reemplazas por 777. Esto hace que el sistema sea inutilizable a menos que restaure manualmente todos los permisos.
En la práctica, es mucho más rápido y fácil de reinstalar.
El problema es que muchos programas del sistema están diseñados de manera que no se inician si "no les gustan" los permisos. Esto se hace por razones de seguridad.
Creo que es más importante explicar cómo manejar el diseño del sistema en paractice que explicar por qué cada programa no funciona con permisos incorrectos.
Si realmente desea que todos los usuarios tengan permisos ilimitados en Ubuntu, puede agregar todos los usuarios al sudogrupo en lugar de cambiar los permisos de archivos y directorios. Eso tendrá el mismo efecto, pero no arruinará el sistema.
Otra forma (muy mala) es activar la cuenta de root y permitir que todos inicien sesión como root.
Tal vez alguien tome tiempo y responda detalladamente ;-)
Pilot6
1
Podría señalar una mejor manera de permitir que todos hagan todo en este sistema, pero escribir un artículo en profundidad sobre por qué cada binario necesita sus permisos, configuraciones e indicadores específicos es demasiado, en mi opinión. ;-)
Phillip -Zyan K Lee- Stockmann
44
Los sistemas Linux no están diseñados para permitir que todos puedan hacer todo. Puede habilitar la cuenta raíz y todos pueden iniciar sesión como root para eso. Es estúpido, pero este es el camino.
Pilot6
99
¿Entonces Pilot6 quiere decir que los programas del sistema han sido diseñados de tal manera que si el permiso falla, entonces no se les permite / no pueden funcionar correctamente? Y, por favor, Pilot6, si es posible, proporcione una respuesta más profunda con ejemplos y explicaciones de por qué ciertas aplicaciones requieren permisos limitados. Gracias.
Brij Raj Kishore
13
@Goldname El error es el error: es un número entero de programas que dicen "No puedo realizar funciones críticas con el sistema en este estado, así que estoy abortando"
Shadur
32
chmod Tiene sutiles matices.
chmod 0777se comporta de manera diferente chmod u+rwx,g+rwx,o+rwxen que setuid y setgid son puestos a cero por el primero y preservados por el segundo.
Es por eso que el sistema se volvió inutilizable. Eliminaste el setuid necesario de algunos programas.
Aquí hay una lista de archivos setuid o setgid en mi laptop Linux Fedora 23:
¿Me atrevo a preguntarme por qué gnuchess y rogue están en esa lista?
WiseOldDuck
2
@WiseOldDuck: Espero que los juegos tengan el bit para que puedan actualizar su archivo de "puntaje alto", pero no permitir que ningún usuario sin privilegios lo haga.
wallyk
3
@WiseOldDuck Como dice wallyk, además, recuerda que setuid no tiene que usar raíz (y afaik setgid no es realmente útil para root)
StarWeaver
55
Levantado por molestarse en explicar lo que chmodestá haciendo y proporcionar evidencia de ejemplo, algo que falta mucho en otros lugares.
underscore_d
1
¿Esto significa que chmod u+rwx,g+rwx,o+rwx -R /no romperá el sistema?
Dennis Jaheruddin
15
Adicional a las otras respuestas: también eliminó el "bit adhesivo" /tmp(que generalmente tiene permisos 1777), y esto podría causar otros problemas inesperados, ya que los programas podrían escribir o eliminar los archivos temporales de los demás.
El bit adhesivo es un permiso especial que, si bien permite que cualquiera pueda crear archivos /tmp, solo permite que la persona que lo creó lo mueva o lo elimine.
"y esto habría evitado que cualquiera que no sea root use el directorio system / tmp" Eso no parece correcto. Todavía permitiría a cualquiera usar el directorio system / tmp. No se necesita un bit fijo si el usuario, el grupo y otros tienen todos los derechos. Sin embargo, permitiría a cualquiera eliminar los archivos de otros.
hvd
1
entonces Ben Si ejecuto chmod 1777 -R / entonces no debería haber ningún problema ya que no estoy limpiando el bit pegajoso. -
Brij Raj Kishore
Gracias @hvd: tienes razón y he cambiado ligeramente la publicación para reflejar eso.
Ben XO
@BrijRajKishore, la pregunta sigue siendo por qué estás haciendo esto en primer lugar. Ubuntu y los programas que lo componen no están diseñados para ejecutarse "sin permiso", por muchas razones. Sería más sensato "su" rootear en su lugar.
Ben XO
1
No se sabe si provocará un bloqueo. Es totalmente posible que así sea, porque de repente las aplicaciones podrán hacer cosas a los archivos temporales de los demás, tal vez accidentalmente, y esto puede causar un bloqueo. Como Ubuntu nunca se prueba de esta manera, probablemente serás la primera persona en descubrirlo. :-) Por otro lado, configurar el bit adhesivo en cada carpeta del sistema puede causar muchos otros problemas, con aplicaciones que esperaban poder manipular programas debido a los permisos de grupo en la carpeta (es decir, carpetas con permisos 2777).
/var/log/syslog
, incluso descubrirías la razón.Respuestas:
Hay un par de razones.
Primero, además de los permisos habituales de lectura / escritura / ejecución, hay otros bits que contienen los permisos de archivo. Lo más notable
setuid
ysetgid
. Cuando se ejecuta un programa con uno de estos bits de permiso, se obtiene el "UID efectivo" y / o el "GID efectivo" del propietario del programa en lugar del usuario que lo ejecutó. Esto permite que los programas se ejecuten con más permisos que el usuario que los ejecutó. Es utilizado por muchas utilidades cruciales del sistema, incluidossu
ysudo
. Suchmod
comando borra estos bits dejando las utilidades inutilizables.En segundo lugar, algunos programas (en particular
ssh
) realizan una comprobación de validez de los permisos de los archivos y se niegan a usar archivos con permisos que consideran inseguros. Esto reduce el riesgo de que administradores descuidados abandonen accidentalmente agujeros de seguridad, pero hace que lidiar con los permisos de archivos eliminados sea aún más doloroso.fuente
Una respuesta corta
El sistema Linux requiere permisos específicos para ciertos programas como
sudo
, etc.Cuando ejecutas
chmod 777 -R /
, borras todos los permisos y los reemplazas por777
. Esto hace que el sistema sea inutilizable a menos que restaure manualmente todos los permisos.En la práctica, es mucho más rápido y fácil de reinstalar.
El problema es que muchos programas del sistema están diseñados de manera que no se inician si "no les gustan" los permisos. Esto se hace por razones de seguridad.
Creo que es más importante explicar cómo manejar el diseño del sistema en paractice que explicar por qué cada programa no funciona con permisos incorrectos.
Si realmente desea que todos los usuarios tengan permisos ilimitados en Ubuntu, puede agregar todos los usuarios al
sudo
grupo en lugar de cambiar los permisos de archivos y directorios. Eso tendrá el mismo efecto, pero no arruinará el sistema.Otra forma (muy mala) es activar la cuenta de root y permitir que todos inicien sesión como root.
fuente
chmod
Tiene sutiles matices.chmod 0777
se comporta de manera diferentechmod u+rwx,g+rwx,o+rwx
en que setuid y setgid son puestos a cero por el primero y preservados por el segundo.Es por eso que el sistema se volvió inutilizable. Eliminaste el setuid necesario de algunos programas.
Aquí hay una lista de archivos setuid o setgid en mi laptop Linux Fedora 23:
Eliminé docenas de entradas de ruido en cachés y registros.
fuente
chmod
está haciendo y proporcionar evidencia de ejemplo, algo que falta mucho en otros lugares.chmod u+rwx,g+rwx,o+rwx -R /
no romperá el sistema?Adicional a las otras respuestas: también eliminó el "bit adhesivo"
/tmp
(que generalmente tiene permisos 1777), y esto podría causar otros problemas inesperados, ya que los programas podrían escribir o eliminar los archivos temporales de los demás.El bit adhesivo es un permiso especial que, si bien permite que cualquiera pueda crear archivos
/tmp
, solo permite que la persona que lo creó lo mueva o lo elimine.fuente