¿Cómo es 'rm -rf /' capaz de borrar todos los archivos en el sistema?

80

No he probado este comando en Ubuntu (por razones obvias), así que no estoy seguro de si Ubuntu permitirá su ejecución. Pero es famoso por eliminar todo. Solo por curiosidad, ¿qué sucede cuando se eliminan kernel y /bin ? ¿Cómo mantiene rm una pila de tiempo de ejecución? ¿Cómo se administra rm para comunicarse con el sistema de archivos y completar la eliminación? ¿Cómo se comunica con el hardware?

    
pregunta Muye 02.04.2015 - 10:13

6 respuestas

76

No importa que /bin/rm se elimine. Solo se ejecuta una vez y en ese momento está todo cargado en la memoria, como lo es todo lo demás para continuar enviando eliminaciones al sistema de archivos y al disco.

Barra lateral / Actualización: según la respuesta de David Hoelzer (y mencionada en los comentarios), el inodo al que el enlace fijo /bin/rm solía apuntar se mantendría hasta que rm terminara (porque Linux mantiene en estado abierto) pero ese hecho es irrelevante; el estado del disco no importa en absoluto.

El binario se carga en la memoria antes de ejecutarse. Incluso si pudiera destruir manualmente los datos de rm del disco, no afectaría o evitaría que la eliminación se completara (suponiendo que no haga que el disco no esté disponible).

No tengo idea de qué es un inodo o hardlink? Esta es la respuesta donde lo resolví.

De todos modos, esta es también la razón por la que puede eliminar el paquete para el kernel actual sin que la computadora implosione. Siempre que instale una versión diferente, podrá iniciarse.

De nuevo, esto funciona porque rm solo se llama una vez. Los siguientes podrían fallar después de que /bin/rm muriera porque lo llama una vez por cada nombre de archivo:

find / -exec rm {} \;

Dicho esto, tanto find / -exec rm -rf {} + como find / -print0 | xargs -0 rm -rf probablemente fallarían porque ambos tienen límites de argumento, lo que significa que solo eliminarían una cantidad de archivos antes de volver a llamar. En algún momento del viaje, /bin/rm podría caducar ( y se liberarán) antes de que el resto de los archivos se eliminen. Sin embargo, no está garantizado. Si /bin/ fuera el último directorio ingresado, estos métodos podrían funcionar.

    
respondido por el Oli 02.04.2015 - 10:26
54
  

No he probado este comando en Ubuntu (por razones obvias), así que no estoy seguro de si Ubuntu permitirá su ejecución.

Lo hice. rm -rf / --no-preserve-root se estaba ejecutando en una sesión de root abierta directamente en la máquina, mientras que también estaba conectado a través de ssh desde otra máquina, también usando la cuenta raíz.

Lo que ocurre es que empiezas a recibir un montón de mensajes como:

  

rm: no se puede eliminar '/ ...': operación no permitida

o:

  

rm: no se puede eliminar '/ ...': dispositivo o recurso ocupado

Sorprendentemente, la conexión ssh permaneció abierta hasta el final de la operación. Solo cuando cerré la conexión e intenté reabrirla, apareció un error:

  

Error de lectura desde el socket: restablecimiento de la conexión por pares

En la máquina, quedan cuatro directorios:

  • /dev . Aquí es donde se almacenan los archivos del dispositivo.
  • /proc -sistema de archivos en memoria creado por el kernel.
  • /run , una ubicación de sistema de archivos estandarizada para daemons.
  • /sys . Esto le permite obtener información sobre el sistema y sus componentes.

Esto significa que no queda mucho, y no hay mucho que hacer allí. No puede ls (aunque cuando se usa la pestaña , los nombres de directorios y archivos aún se muestran). Puede cd en directorios diferentes, y también echo stuff, pero comandos como cat ya no están disponibles.

Tampoco hay sudo .

shutdown -h now y reboot desaparecieron también, por lo que su única opción parece apagar la máquina manualmente. El cierre de sesión ( exit ) no funciona, incluso si muestra un buen texto de "cierre de sesión".

Una vez que intenta reiniciar la máquina, se le presenta un agradable error de GRUB 15, y luego, no ocurre nada, en ese punto puede comenzar a pensar que su rm podría haber hecho algo malo en su sistema.

Puedes hacerlo también

¡No, espera, no lo hagas en tu máquina!

Lo que puede hacer en su lugar es ejecutar una máquina virtual . Las VM tienen la ventaja de hacer que la experimentación sea realmente fácil. Dado que está utilizando Ubuntu, puede estar interesado en vmbuilder . Esta es una herramienta que le permite implementar máquinas virtuales en cuestión de minutos (la documentación oficial afirma que se puede hacer "en aproximadamente un minuto", pero el tiempo real, incluso en hardware rápido, es más o menos de dos o tres minutos). .

Una vez que finaliza la implementación, tiene un entorno con el que puede jugar. Si terminas destruyéndolo, no importa: vuelves a desplegar la máquina y, dos minutos después, puedes continuar.

Si utiliza software como VMWare, también podría estar interesado en instantáneas (tenga en cuenta que el reproductor VMWare gratuito no tiene esta función, debe comprar VMware Workstation). Tenga en cuenta que Hyper-V es gratuito y admite instantáneas (pero debe ejecutar Windows).

El beneficio de las instantáneas es que puede tomar una en cuestión de milisegundos. Volver a una instantánea lleva más tiempo, pero a menudo es cuestión de segundos. Esto hace que la experimentación sea aún más fácil y más rápida.

Esta experimentación no se limita al sistema operativo en sí. Puedes hacer todo tipo de cosas relacionadas con el software. ¿Tienes una aplicación sospechosa? Pruébelo en una VM: si es un virus, no hará ningún daño. ¿Desea probar una operación en una base de datos, dado que podría afectar el medio ambiente? Pruébalo en una máquina virtual.

¿Qué pasa si lo hiciste en una máquina real sin prueba?

Suceden cosas malas. Tenga en cuenta que rm lo protege de usted: rm -rf / no funcionará: necesita usar --no-preserve-root . Aún así, ¿qué pasa si realmente logras, por error, eliminar todo?

rm solo desvincula los archivos , pero los datos aún están allí, en su disco duro. Esto hace que sea posible recuperarlo más tarde (por lo que no debería tirar los discos duros con datos confidenciales cuando ya no funcionan).

Esto significa que solo tiene que tener una PC de repuesto con un gabinete de disco duro para recuperar casi todos los archivos. Lo importante es evitar escribir algo en el disco duro para su recuperación: los datos que escriba sobrescribirán los archivos no vinculados.

Como lo señala el artículo en el comentario de 200_success , si actúa de manera inteligente , puede recuperar la máquina incluso sin una PC de repuesto. Si le importan los datos, no me molestaría; recuperarla con una PC de repuesto es mucho más fácil.

    
respondido por el Arseni Mourzenko 02.04.2015 - 20:06
25

La razón es que la capa de nombre del archivo (lo que se ve con ls ) es realmente solo para su conveniencia. El controlador del sistema de archivos y el kernel solo se preocupan por el inodo. Cuando se hace referencia a un archivo por nombre, se traduce inmediatamente al inodo que contiene todos los metadatos, incluidos los permisos, los bloques de datos en el disco, la ID del propietario, la ID del grupo y el recuento de enlaces.

La cantidad de enlaces es lo que realmente importa aquí. Cuando elimina un archivo en un sistema UNIX, la llamada al sistema real es un unlink . Lo que sucede bajo el capó es que el recuento de enlaces (el número de nombres de archivo en la capa de nombres de archivos) que apunta a ese inodo disminuye. El sistema de archivos sabe que un archivo se elimina cuando el número de enlaces llega a cero.

Cuando un archivo es borrado por rm , también editará el archivo de directorio (sí, es solo un archivo que contiene el nombre de archivo y el inodo, además de algunos otros bits que no son importantes para esta respuesta). Sin embargo, es la desvinculación la que realmente libera los recursos del disco.

Esto lleva a algunos otros efectos interesantes. Primero, es posible tener un archivo abierto cuyo conteo de enlaces es cero. Esto sucede cuando rm -rf / elimina la entrada para /bin/rm . El archivo está abierto (hay un identificador de archivo) pero el inodo está marcado como eliminado (número de enlaces = 0). Los recursos del disco no se liberarán ni se reutilizarán hasta que se cierre el identificador del archivo.

Otro efecto interesante es lo que sucede cuando tienes un inodo con un conteo de enlaces mayor que cero, pero no hay nada en la capa de nombres de archivo que lo señala. Este es, en cierto sentido, un archivo muy bien oculto :). Para tener acceso a él, debe usar algo de bajo nivel para referenciarlo por número de inodo en lugar de por nombre (porque no hay uno) o edite una entrada de directorio para apuntar al inodo usando un editor hexadecimal.

Un tercer efecto interesante es lo que sucede si reduces el recuento de enlaces a cero pero apuntas una entrada de directorio al inodo de todos modos. Te dejaré eso para que experimentes si lo deseas. Claramente, sin embargo, estos dos últimos conducen al sistema de archivos en un estado inconsistente.

    
respondido por el David Hoelzer 02.04.2015 - 15:08
18

Las respuestas anteriores son buenas, pero quiero aclarar un detalle:

rm no es solo un comando. Es un programa que se encuentra en PATH .

Por lo tanto, lo que sucede cuando se ejecuta es lo siguiente:

  • llamas (como root) rm -rf /
  • instancia del programa rm se carga en la memoria con los argumentos -rf y /
  • basado en estos argumentos, el programa rm inicia sus operaciones (repasando todo en montado / partición y eliminando referencias de forma recíproca [lo siento por tecnicidad;)])
  • una vez que finaliza, la instancia del programa rm se descarga
  • en este punto, las únicas cosas en la memoria son los programas que se cargaron allí previamente (por ejemplo, bash si tiene la terminal abierta en Ubuntu, entorno de escritorio, kernel, controladores, etc.)
  • si intenta llamar a cualquier otro comando (que en el caso de Linux lo convierte en un programa independiente), fallará porque no se encuentra dicho programa en las ubicaciones PATH (y las ubicaciones PATH ya no existen). Sin embargo, todo lo que cargó una vez seguirá ejecutándose

Solo por el bien de entender cómo funciona, intente instalar LAMP en ubuntu (en Virtualbox), algo de script y caché de código de operación PHP, luego llame a este malvado comando. Sorprendentemente (si tienes suerte y tu caché de código de operación no notará la eliminación del archivo php) aún puedes acceder a los scripts php desde el exterior a través del servidor web apache.

PD: este mal comando incluso se ejecutó como raíz no eliminará everything , no puede eliminar algunos procesos con privilegios del núcleo de /proc y no puede eliminar algunas cosas de /dev dispositivos que aparecen en su sistema como archivos. De hecho, root no es tan omnipotente como creemos, kernel por otro lado sí.

PPS: también como segundo pensamiento, también tendrás archivos que fueron locked por otro proceso en el momento del intento de eliminación.

    
respondido por el Alexey Kamenskiy 02.04.2015 - 13:45
1

Una vez que todo se borró de los discos duros, el kernel sigue funcionando, pero se bloquea porque no hay dispositivos y programas, comandos, etc. restantes.

El sistema operativo ya no funcionará.

Y es verdad lo que dice Oli, el comando se carga / ejecuta en la memoria y nada lo detendrá a menos que mates este proceso (por supuesto, si el comando kill está todavía presente ^^).

    
respondido por el s1mmel 02.04.2015 - 11:35
0

Tenga en cuenta que si el sistema tiene selinux y selinux está en modo obligatorio, y las políticas de selinux están configuradas correctamente; entonces no pasará mucho.

Selinux es un control de acceso obligatorio, lo que significa, entre otras cosas, que el usuario raíz realmente no tiene mucha más potencia para destruir el sistema que cualquier otro usuario en el sistema.

Selinux se aplica en el kernel; tendrías que comprometer el núcleo para evitarlo.

En un sistema bien diseñado con buenas políticas de Selinux, root no podría hacer mucho en el sistema.

Las últimas revisiones de Android hacen que Selinux se aplique solo por esta razón.

    
respondido por el Mark Allyn 03.04.2015 - 04:38

Lea otras preguntas en las etiquetas