Pregunta ¿Qué tan lejos llegarás con un comando 'rm -rf /'?


A menudo me he preguntado qué tan lejos llegará el sistema si corres rm -rf /. Dudo que el sistema operativo sea capaz de borrarse a sí mismo (?)

Pregunta extra: Después de que se haya ejecutado el comando, rm se han eliminado?

Actualizar: 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, encontré algunos problemas cuando uso una versión de rm que no sea la de GNU. Por ejemplo, creo que BusyBox tiene su propia versión y no le permite eliminar todo lo que potencialmente pueda.

Esta pregunta fue una Pregunta del Superusuario de la semana.
  Lea el 7 de julio de 2011 Entrada de blog para más detalles o envía tu propio Pregunta de la semana.


200


origen


Es gracioso que hayas hecho esta pregunta. Estaba respondiendo otra pregunta de rm -f en otro foro y comencé a recordar un artículo que leí hace un tiempo. Afortunadamente lo guardé en momentos como este: EL historia de terror clásica de Unix Además del hecho de que es interesante ver hasta dónde llegará ... ¡creo que es un artículo muy bien escrito y en general es una buena lectura! - akseli
Acabo de intentar sudo rm -rf / en tinycore / microcore Linux y parece que el SO protege varios directorios (/ sys y otros) de ser eliminados. - n0pe
Lo intenté rm -f /bin/rm una vez. Desafortunadamente, funcionó, y pasé la siguiente hora obteniendo la versión correcta de rm de regreso de GNU coreutils. - squircle
Espera un momento, intentaré ... - Martijn Courteaux
Hago esto en la tienda de manzanas todo el tiempo - eggie5


Respuestas:


Si usted tiene rm de GNU coreutils (muy probablemente si es una distribución regular de Linux), rm -rf / será rechazado por la protección incorporada (de acuerdo con la página de manual y Wikipedia, no lo han intentado).

Puede anular esta protección con --no-preserve-root. rm luego 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 /proc y /sys, pero eso es irrelevante: eliminará todo en su disco.

Después de que finalice el comando, su disco se borrará, incluido el sistema operativo. El kernel y los procesos actuales seguirán ejecutándose desde la memoria, pero muchos procesos morirán porque no podrán acceder a ningún archivo. El SO no arrancará la próxima vez.


188



Exactamente lo que estaba buscando. Ahora para usar este poder PARA LLEVAR AL MUNDO. - n0pe
+1 especialmente para --no-preserve-root porque eso generalmente no se menciona. - Matěj G.
@MaxMackie, vale la pena señalar que los piratas informáticos encontraron rápidamente que este era el menos cosa útil que podrían hacerle a un usuario. Destruye cualquier dato que pueda usarse para obtener ganancias en efectivo e impide que el pirata informático explote más la máquina. Como un gato con un insecto, no quieres matarlo, solo quieres jugar con él por un tiempo porque es divertido. - zzzzBov
Para responder a la otra pregunta de OP, sí rm se eliminará solo. Es totalmente posible modificar o eliminar un archivo ejecutable incluso cuando hay una instancia en ejecución. Seguirá funcionando, también, y no se verá afectado por el cambio. - thomasrutter
Me gustaría mencionar "chmod -R usuario: usuario *" en / porque también es un error recursivo y costoso. Lo hice una vez, y ya había llegado a la mitad de mi hogar cuando pude abortar. / bin / boot / etc / dev eran de su propiedad. Afortunadamente, el servidor siguió funcionando mientras yo pasaba las próximas horas de forma manual y restablecía las propiedades de un sistema de referencia. Sin embargo, nadie más podría usar su o sudo después. Eventualmente descubrió que / bin / su ya no tenía establecido su bit setuid. Tome nota para el futuro: ¡chowning / bin / su restablece su bit de setuid! - Andy Lee Robinson


Para aquellos que les gusta hacer cosas como esta visualmente mientras escuchan música techno.

Ejecutando rm-rf en Linux (video)

Puntos de bonificación si puede nombrar los procesos cuando comienzan a morir.


41





Configurar una máquina virtual y tratar de divertirse?

Llegará bastante lejos ... si usa una interfaz gráfica de usuario, podría divertirse al notar que las cosas se degradan de manera más visible. (los íconos 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 hacer una reinstalación del SO.


22



Ni siquiera pensé en probarlo en una máquina virtual. ¡Vamos a intentar ahora! ooo esto es divertido. - n0pe
Erróneamente escribe el comando a la Terminal del sistema host - slhck
Mira el artículo que publiqué. "¡La clásica historia de horror de Unix!" - akseli
Estoy trabajando ahora mismo 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, sería increíble. - n0pe
Con Amazon EC2 debería ser rápido encender uno de sus AMI que ya tiene linux instalado y disparar ... - David d C e Freitas


Bueno, probándolo http://bellard.org/jslinux/ produce:

rm: no se puede eliminar '/ dev / pts': dispositivo o recurso ocupado
  rm: no se puede eliminar '/ dev': el directorio no está vacío
  rm: no se puede eliminar '/ proc / swaps': operación no permitida
  rm: no se puede eliminar '/ proc / kallsyms': operación no permitida
  rm: no se puede eliminar '/ proc / dma': operación no permitida

Entradas SNIP 881

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


11



Sí, recibo esos errores / advertencias también. ¿Es este estándar lo que piensas? - n0pe
/ proc, / sys, a veces / dev y cualquier punto de montaje son propiedades del sistema operativo y no se pueden eliminar. - pjc50
Al igual que @ pcj50, esos no son literalmente archivos en el disco duro, por lo que "borrarlos" no es significativo. - CarlF


Recuerdo que esto se mordió en alt.sysadmin.recovery en los días de antaño, cuando no existía nada /procy /dev era solo un directorio regular que contenía entradas para un montón de inodos inusuales ...

... pero, en algunas variantes de Unix (mi recuerdo es HP-UX, pero eso podría ser totalmente erróneo), podrías no eliminar la última entrada de directorio para un programa que se estaba ejecutando. (¿Bibliotecas compartidas? ¿Cuáles son esas?)

En tales sistemas, si inició uno en modo de mantenimiento (por lo que no se ejecutaba nada excepto su caparazón, ni siquiera init, y no se montaron sistemas de archivos secundarios) y exec /bin/rm -rf /, se quedaría con un sistema de archivos raíz completamente vacío excepto ese /bin y /bin/rm sobreviviría

Los habitantes del temible monasterio del diablo consideraron que esto era apropiado y apropiado.


7





rm -rf / no debe 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, obtuvimos la especificación modificada, y Solaris 10 tiene (desde la versió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] 

4



"señalando que si uno intenta eliminar" / "recursivamente, uno finalmente intentará eliminar" .. "y". ", y que todo lo que estamos haciendo es permitir que rm determine esto de forma heurística. ! "- eh, ¿eso no impediría eliminar alguna ¿directorio? La especificación real solo deshabilita ... y. en los argumentos reales de la línea de comandos, no dice nada sobre lo que "finalmente intentas eliminar" - Random832
¿Por qué no se permite eliminar ningún 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
Esa línea de argumentación es puro genio. - Nate C-K
El estándar especifica que rm no puede continuar si un argumento tiene la cadena "." o ".." como el componente del nombre base. No puedes eliminar /foo/.. incluso si no estás en /foo. Lo hace no especifique que no tiene permitido eliminar el directorio actual (p. rm -r `pwd`) o el padre del directorio actual. - Random832
De hecho, malentendí la declaración y estás en lo cierto. Con suerte, los tipos estándar aceptaron el comportamiento más inteligente como estándar. La eliminación de partes grandes, si no de todo el sistema de archivos, haría rápidamente que el sistema operativo no fuera compatible con las normas de todos modos. - jlliagre


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


3



Así es, porque están cargados en la memoria, ¿verdad? - n0pe
No estoy seguro de si es seguro asumirlo; el kernel podría simplemente 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 se ejecute rm). - Ambroz Bizjak
No estoy especulando. Si un programa se está ejecutando, eliminarlo no lo elimina en mis cuadros de Linux, al menos. (Tenga en cuenta que no he probado esto en, oh, un par de años). - CarlF
rm  será eliminarse del fs - el programa está completamente cargado en la memoria, no en el archivo - warren
@MaxMackie: no porque estén cargados en la memoria, sino porque una referencia de archivo abierto tiene la misma potencia que un enlace físico (es decir, si un archivo tiene al menos un enlace fijo, no se eliminará del disco). - Lie Ryan


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


1



"[no borró] solo el proceso que era esencial para el SO" - oh, no te preocupes. A diferencia de Windows, Linux borrará cualquier cosa, incluso si el archivo es crítico para el sistema operativo. y en uso. /boot, /sbin, /etc, /bin, /vmlinuz? Bam, se fue. Buena suerte arrancando sin esos - de hecho, buena suerte haciendo cualquier cosa en absoluto una vez que la eliminación haya finalizado. - Piskvor
Si recuerdo que hubo algún archivo que no se eliminó, y dejo 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
"chmod 777 / * -fR" - Eso debería hacer que el sistema sea muy inseguro, aunque muy fácil de usar. - Bart van Heukelom
lo hizo, es muy inseguro. No puedes hacer nada, algunos procesos deben tener un derecho específico, y el chmod 777 cambiará cada derecho, nunca serás capaz de cargar una sesión, y algunos procesos lo harán. - Anarko_Bizounours
@BartvanHeukelom, algunas herramientas realizarán una autocomprobación rápida, o el sistema las probará en cuanto a la propiedad y los permisos adecuados, y se negará a actuar si están mal configuradas. - killermist


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

Pero para responder a su pregunta básica, sí, rm comando se eliminará con él, así como cualquier otro comando estándar en /bin y otras carpetas.

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

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

    vagrant init ubuntu/vivid64 && vagrant up --provider virtualbox && vagrant ssh
    
  2. Luego, cuando intenta eliminar todos los archivos de la manera estándar, no le 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. Entonces intentemos --no-preserve-root. Siempre compruebe dos veces que está conectado a la máquina virtual (por lo que está teniendo vagrant@vagrant-ubuntu-vivid-64:~$), luego corre (no intentes 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 prompt de la shell como si nada acabara de pasar, pero ya no puedes ejecutar ningún comando aparte de algunos integrados y kill, para que pueda 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.
    

Así que eliminó todo, incluso rm, ls y todos los demás comandos, pero todavía estás conectado. Hay algunas carpetas especiales que no se eliminaron, como algunos dispositivos de /dev, /proc o /sys que no son directorios / archivos regulares, pero es un sistema de archivos pseudo que proporciona interfaces para procesar y datos del kernel.

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

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


1