¿Hasta dónde llegarás con un comando 'rm -rf /'?

200

A menudo me he preguntado qué tan lejos llegará el sistema si corres rm -rf /. Dudo que el sistema operativo pueda borrarse solo (?)

Pregunta de bonificación : Después de que se haya ejecutado el comando, ¿se rmhabrá eliminado?

Actualización: He probado esto en un par de las principales distribuciones de Unix usando VirtualBox y las respuestas describen exactamente lo que sucede. Si se le dan los parámetros correctos, rm eliminará cada bit físico de datos en el disco. Sin embargo, me encontré con algunos problemas al usar una versión de rm que no sea GNU. Por ejemplo, creo que BusyBox tiene su propia versión y no le permite eliminar tanto como podría potencialmente.

Esta pregunta fue una pregunta de superusuario de la semana .
Lea la entrada del blog del 7 de julio de 2011 para obtener más detalles o envíe su propia Pregunta de la semana.

unix  filesystems  rm 
— n0pe
fuente
8
Es curioso que hayas hecho esta pregunta. Estaba respondiendo otra pregunta rm -f en otro foro y comencé a recordar un artículo que leí hace un tiempo. Afortunadamente lo guardé para momentos como este: LA clásica historia de terror de Unix Además del hecho de que es interesante ver qué tan lejos llegará ... ¡Creo que es un artículo muy bien escrito y en general es una buena lectura!
— akseli
3
Acabo de probar sudo rm -rf /en tinycore / microcore linux y parece que el sistema operativo protege varios directorios (/ sys y otros) de ser eliminados.
— n0pe
47
Lo intenté rm -f /bin/rmuna vez. Desafortunadamente, funcionó, y pasé la siguiente hora obteniendo la versión correcta rmde GNU coreutils.
— ardilla
17
Espera un segundo, lo intentaré ...
— Martijn Courteaux
38
Hago esto en la tienda de Apple todo el tiempo
— eggie5

Respuestas:

188

Si tiene rmCoreutils de GNU (muy probablemente si es una distribución regular de Linux), rm -rf /la protección incorporada lo rechazará (según la página de manual y Wikipedia, no lo he intentado).

Puede anular esta protección con --no-preserve-root. rmluego eliminará todo lo que pueda, sin detenerse después de haber intentado eliminar cada archivo. Por supuesto, no eliminará los sistemas de archivos virtuales como /procy /sys, pero eso es irrelevante: eliminará todo en su disco.

Una vez que finalice el comando, su disco se borrará vacío, incluido el sistema operativo. El núcleo y los procesos actuales continuarán ejecutándose desde la memoria, pero muchos procesos morirán porque no podrán acceder a algún archivo. El sistema operativo no se iniciará la próxima vez.

— Ambroz Bizjak
fuente
67
Exactamente lo que estaba buscando. Ahora para usar este poder para conquistar el mundo.
— n0pe
34
+1 especialmente --no-preserve-rootporque eso generalmente no se menciona.
— Matěj G.
22
@MaxMackie, vale la pena señalar que los piratas informáticos encontraron rápidamente que esto era lo menos útil que podían hacer a un usuario. Destruye cualquier dato que pueda usarse para obtener ganancias en efectivo y evita que el pirata informático siga explotando la máquina. Como un gato con un insecto, no quieres matarlo, solo quieres jugar con él por un tiempo porque es divertido.
— zzzzBov
55
Para responder a la otra pregunta del OP, sí rm se eliminará. Es completamente posible modificar o eliminar un ejecutable incluso cuando hay una instancia de él ejecutándose. También seguirá funcionando y no se verá afectado por el cambio.
— thomasrutter
3
Me gustaría mencionar "chmod -R user: user *" en /, porque también es un error recursivo y costoso. Lo hice una vez, y había llegado a la mitad / a casa cuando pude abortar. / bin / boot / etc / dev eran de propiedad. Afortunadamente, el servidor siguió funcionando mientras pasaba las siguientes horas manualmente y restablecía la propiedad de un sistema de referencia. Sin embargo, nadie más podría usar su o sudo después. Finalmente descubrió que / bin / su ya no tenía su bit setuid establecido. Tome nota para el futuro: chowning / bin / su restablece su bit setuid!
— Andy Lee Robinson
22

¿Configurar una VM e intentar divertirse?

Llegará bastante lejos ... si está usando una interfaz gráfica de usuario, puede divertirse notando que las cosas se degradan de manera más visible. (los iconos en los menús dejan de cargarse, etc.)

Si lo dejas ir, el sistema operativo estará más allá de la recuperación, aunque es posible que puedas recuperar algunos datos fácilmente.

De cualquier manera, querrás volver a instalar el sistema operativo.

— PriceChild
fuente
77
Ni siquiera pensé en probarlo en una máquina virtual. ¡Voy a probar ahora! ooo esto es divertido
— n0pe
40
Escribe el comando por
— error en
1
Mira el artículo que publiqué. "¡La clásica historia de terror de Unix!"
— akseli
1
Estoy en el trabajo en este momento y no tengo tiempo para realizar una instalación completa de una distribución popular (ubuntu / slack / suse / fedora). Si alguien más puede clonar un archivo de disco VM y probarlo por nosotros, sería increíble.
— n0pe
2
Con Amazon EC2, debería ser rápido encender uno de sus AMI que ya tienen Linux instalado y disparar ...
— David d C e Freitas
11

Bueno, probarlo en http://bellard.org/jslinux/ produce:

rm: no se puede eliminar '/ dev / pts': Dispositivo o recurso ocupado
rm: no se puede eliminar '/ dev': Directorio no vacío
rm: no se puede eliminar '/ proc / swaps': Operación no permitida
rm: can 't remove' / proc / kallsyms ': Operación no permitida
rm: no se puede eliminar' / proc / dma ': Operación no permitida

SNIP 881 entradas

rm: no se puede eliminar '/ proc / 149 / oom_adj': Permiso denegado
rm: no se puede eliminar '/ proc / 149': Operación no permitida
rm: no se puede eliminar '/ proc': Dispositivo o recurso ocupado
rm: no se puede eliminar '/ tmp': dispositivo o recurso ocupado
rm: no se puede eliminar '/': dispositivo o recurso ocupado

— Hola71
fuente
1
Sí, también recibo esos errores / advertencias. ¿Es este el estándar que piensas?
— n0pe
55
/ proc, / sys, a veces / dev, y cualquier punto de montaje son propiedades del sistema operativo y no se pueden eliminar.
— pjc50
1
Simultáneamente con @ pcj50, esos no son literalmente archivos en el disco duro, por lo que "eliminarlos" no tiene sentido.
— CarlF
7

Recuerdo que esto se masticaba alt.sysadmin.recoveryen días anteriores, cuando no existía tal cosa /proc, y /devera solo un directorio normal que contenía entradas para un montón de inodos inusuales ...

... pero, en algunas variantes de Unix (mi recuerdo es HP-UX, pero que podría estar totalmente equivocado), podría no eliminar la última entrada de directorio para un programa que se estaba ejecutando. (¿Bibliotecas compartidas? ¿Qué son esas?)

En tales sistemas, si iniciado una en modo de mantenimiento (así que nada estaba funcionando, pero su cáscara, ni siquiera init, y se montaron ningún sistema de archivos secundarios) e hizo exec /bin/rm -rf /, que se quedaría con un sistema de archivos raíz completamente vacía a excepción de que /biny /bin/rmlo harías sobrevivir.

Los habitantes del aterrador monasterio del diablo consideraban que esto era apropiado y apropiado.

— zwol
fuente
4

rm -rf / no debería permitirse en implementaciones recientes, ya que se ha sugerido que viola el estándar POSIX:

" rm -rf /" protección en el blog de Oracle

De todos modos, al final, modificamos la especificación, y Solaris 10 tiene (desde la compilación 36) una versión de / usr / bin / rm (/ bin es un enlace simbólico a / usr / bin en Solaris) y / usr / xpg4 / bin / rm que se comporta así:

[28] /bin/rm -rf /
rm of / is not allowed
[29]
— jlliagre
fuente
2
"señalando que si uno intenta eliminar" / "de forma recursiva, finalmente intentará eliminar" .. "y". ", y que todo lo que estamos haciendo es permitir que rm determine previamente esto de forma heurística. Sorprendentemente, compraron eso ! "- er, ¿eso no permitiría eliminar ningún directorio? La especificación real solo no permite ... y. en los argumentos de línea de comandos reales, que no dice nada acerca de lo que "en última instancia, intentar quitar"
— Random832
1
¿Por qué no permitiría eliminar cualquier directorio? El directorio raíz es el único afectado aquí y eliminarlo obviamente implica eliminar ". y "..", cualquiera que sea el directorio actual. El sentido común no está prohibido en la interpretación estándar.
— jlliagre
1
Esa línea de argumentación es pura genialidad.
— Nate CK
El estándar especifica que rm no puede continuar si un argumento tiene la cadena "." o ".." como el componente basename. No puedes eliminar /foo/..incluso si no estás dentro /foo. No , no se especifica que no se le permite eliminar el directorio actual (por ejemplo rm -r `pwd`) o el padre del directorio actual.
— Random832
2
De hecho, no entendí bien la declaración y estás en lo correcto. Con suerte, los chicos estándar aceptaron que el comportamiento más inteligente cumplía con los estándares. Eliminar partes grandes, si no todo el sistema de archivos, rápidamente haría que el sistema operativo no cumpla con los estándares de todos modos.
— jlliagre
3

Un punto que no vi hecho por nadie más: los archivos que están abiertos actualmente (por ejemplo, rm), incluso si se eliminan, en realidad no desaparecerán de la unidad hasta que se cierren.

— CarlF
fuente
Así es, porque están cargados en la memoria ¿verdad?
— n0pe
No estoy seguro de si es seguro asumirlo; el núcleo podría muy bien cargar el archivo eliminado en la memoria y eliminarlo en el disco de inmediato, y mantener esta copia en la memoria hasta que el archivo esté abierto (por ejemplo, hasta que rm se esté ejecutando).
— Ambroz Bizjak
No estoy especulando Si se está ejecutando un programa, eliminarlo no lo elimina en mis cuadros de Linux, al menos. (Eso sí, no he probado esto en, oh, un par de años.)
— CarlF
44
rm se eliminará de la fs - el programa está completamente cargado en la memoria, no el archivo
— warren
44
@MaxMackie: no porque estén cargados en la memoria, sino porque una referencia de archivo abierto tiene la misma potencia que un enlace duro (es decir, si un archivo tiene al menos un enlace duro, no se eliminará del disco).
— Lie Ryan
1

Por haberlo intentado una vez (en un servidor que me molesta), registrado como root, en la terminal, perderá casi todo. Lo único que no se borrará será solo el proceso que fue esencial para el sistema operativo.

— Anarko_Bizounours
fuente
12
"[no borrado] solo el proceso que era esencial para el sistema operativo" - oh, no te preocupes. A diferencia de Windows, Linux borrará cualquier cosa, incluso si el archivo es crítico para el sistema operativo y está en uso. /boot, /sbin, /etc, /bin, /vmlinuz? Bam, se fue. Buena suerte arrancando sin ellos; de hecho, buena suerte haciendo cualquier cosa una vez que finalice la eliminación.
— Piskvor
Si recuerdo que hubo algún archivo que no se eliminó, y dejé que mi Linux se ejecute durante más de 4 horas. Pero aún así, es bueno saber qué sucede, como hacer un chmod 777 / * -fR;)
— Anarko_Bizounours
3
"chmod 777 / * -fR" - Eso debería hacer que el sistema sea muy inseguro, aunque muy fácil de usar.
— Bart van Heukelom
1
@BartvanHeukelom, algunas herramientas realizarán una autocomprobación rápida, o el sistema las probará para obtener la propiedad y los permisos adecuados y se negará a actuar si está mal configurado.
— killermist
1
chmod -fR 777 /es dañino porque apaga los bits setuid y setgid.
— G-Man
1

Hasta dónde puede llegar, depende básicamente de las distribuciones específicas de Unix / Linux.

Pero para responder a su pregunta básica, sí, el rmcomando se eliminaría junto con cualquier otro comando estándar en /biny otras carpetas.

Aquí está la prueba simple que he realizado en Linux Ubuntu 15.04 usando VM.

  1. Inicialice la máquina virtual a través de vagrant:

    vagrant init ubuntu/vivid64 && vagrant up --provider virtualbox && vagrant ssh

  2. Luego, cuando intentas eliminar todos los archivos de la manera estándar, no te permite:

    vagrant@vagrant-ubuntu-vivid-64:~$ sudo rm -fr /
rm: it is dangerous to operate recursively on '/'
rm: use --no-preserve-root to override this failsafe

  3. Así que vamos a intentarlo --no-preserve-root. Siempre verifique que haya iniciado sesión en la máquina virtual (por lo que está teniendo vagrant@vagrant-ubuntu-vivid-64:~$), luego ejecute (no intente eso en casa):

    vagrant@vagrant-ubuntu-vivid-64:~$ sudo rm -vfr --no-preserve-root /
removed directory: '/lost+found'
removed directory: '/opt'
removed '/bin/nc'
removed '/bin/less'
removed '/bin/wdctl'
removed '/bin/nano'
...
removed '/bin/rmdir'
removed '/bin/sh'
removed '/bin/rm'
...
removed directory: '/bin'
removed directory: '/usr/games'
removed '/usr/bin/byobu-launcher-install'
removed '/usr/bin/ipcmk'
removed '/usr/bin/sum'
removed directory: '/usr/bin'
removed '/usr/lib/gcc/x86_64-linux-gnu/4.9.2'
removed '/usr/lib/gcc/x86_64-linux-gnu/5.0.1'
removed directory: '/usr/lib/gcc/x86_64-linux-gnu/5'
removed '/usr/lib/gcc/x86_64-linux-gnu/4.9/libquadmath.so'
removed '/usr/lib/gcc/x86_64-linux-gnu/4.9/libgomp.so'
...
removed directory: '/run/initramfs'
removed directory: '/media'
rm: cannot remove '/proc/fb': Operation not permitted
rm: cannot remove '/proc/fs/ext4/sda1/options': Operation not permitted
...
removed '/vmlinuz'
removed '/boot/config-3.19.0-23-generic'
removed '/boot/grub/grubenv'
...
removed directory: '/boot'
removed '/lib64/ld-linux-x86-64.so.2'
rm: cannot remove '/dev/hugepages': Device or resource busy
rm: cannot remove '/dev/mqueue': Device or resource busy
rm: cannot remove '/dev/shm': Device or resource busy
removed '/dev/vcsa7'
...
removed '/dev/mem'
removed '/dev/rfkill'
removed '/dev/vga_arbiter'
...
rm: cannot remove '/sys/fs/ecryptfs/version': Operation not permitted
removed directory: '/etc'
removed directory: '/mnt'
removed '/vagrant/.vagrant/machines/default/virtualbox/action_provision'
removed '/vagrant/.vagrant/machines/default/virtualbox/action_set_name'
removed '/vagrant/.vagrant/machines/default/virtualbox/creator_uid'
removed '/vagrant/.vagrant/machines/default/virtualbox/id'
removed '/vagrant/.vagrant/machines/default/virtualbox/index_uuid'
removed '/vagrant/.vagrant/machines/default/virtualbox/private_key'
removed '/vagrant/.vagrant/machines/default/virtualbox/synced_folders'
removed directory: '/vagrant/.vagrant/machines/default/virtualbox'
removed directory: '/vagrant/.vagrant/machines/default'
removed directory: '/vagrant/.vagrant/machines'
removed directory: '/vagrant/.vagrant'
removed '/vagrant/Vagrantfile'
rm: cannot remove '/vagrant': Device or resource busy

    Después de eso, vuelve al indicador de shell como si nada hubiera pasado, pero ya no puede ejecutar ningún comando aparte de los pocos integrados kill, por lo que puede terminar su trabajo y matar su sesión :)

    Por ejemplo:

    $ rm
rm: command not found
$ kill
kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or kill -l [sigspec]
$ which kill
-bash: /usr/bin/which: No such file or directory
$ kill -9 $$
Connection to 127.0.0.1 closed.

Por lo que prácticamente elimina todo, incluso rm, lsy todos los otros comandos, pero todavía estás registrado de entrada. Hay algunas carpetas especiales que no se eliminaron, como algunos dispositivos /dev, /proco /sysque no son directorios / archivos normales, pero es un pseudo sistema de archivos que proporciona interfaces para procesar y datos del núcleo.

Si no tiene Vagrant o Linux, puede jugar con algunos emuladores JavaScript Linux x86 .

Si está interesado en las posibilidades de recuperarse de tal desastre, verifique:

— kenorb
fuente
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.