Até onde você vai chegar com um comando 'rm -rf /'?

199

Eu sempre me perguntei até que ponto o sistema realmente chegará se você executar rm -rf / . Eu duvido que o sistema operacional seria capaz de se apagar (?)

Pergunta bônus : Após o comando ser executado, rm será removido?

Atualização: Eu testei isso em algumas das principais distribuições unix usando o VirtualBox e as respostas descrevem exatamente o que acontece. Se forem fornecidos os parâmetros corretos, o rm removerá todos os dados físicos do disco. No entanto, me deparei com alguns problemas ao usar uma versão do rm diferente da GNU. Por exemplo, acredito que o BusyBox tem sua própria versão e não permite que você remova tanto quanto você poderia potencialmente.

This question was a Super User Question of the Week.
Read the July 7th, 2011 blog entry for more details or submit your own Question of the Week.

    
por n0pe 20.07.2011 / 15:48

9 respostas

188

Se você tem rm do GNU coreutils (provavelmente se for uma distribuição regular do Linux), rm -rf / será recusado pela proteção embutida (de acordo com manpage e Wikipedia, não tentei isso). / p>

Você pode substituir essa proteção por --no-preserve-root . rm removerá tudo o que for possível, sem parar depois de tentar remover todos os arquivos. É claro que não removerá sistemas de arquivos virtuais como /proc e /sys , mas isso é irrelevante - removerá tudo no disco.

Depois que o comando terminar, seu disco será apagado, incluindo o sistema operacional. O kernel e os processos atuais continuarão a rodar a partir da memória, mas muitos processos morrerão porque não conseguirão acessar algum arquivo. O sistema operacional não inicializará da próxima vez.

    
por 20.07.2011 / 16:36
41

Para quem gosta de fazer coisas desse tipo visualmente enquanto ouve música techno.

Executando rm-rf no Linux (vídeo)

pontos de bônus, se você pode nomear os processos como eles começam a morrer.

    
por 21.07.2011 / 01:23
22

Configurar uma VM e tentar por diversão?

Vai muito longe ... se você estiver usando um gui você pode se divertir notando que as coisas se degradam mais visivelmente. (ícones nos menus param de carregar, etc.)

Se você deixar passar, o sistema operacional estará praticamente fora de recuperação, embora você possa recuperar alguns dados com facilidade.

De qualquer forma, você vai querer fazer uma reinstalação do sistema operacional.

    
por 20.07.2011 / 15:52
11

Bem, experimentá-lo no link produz:

rm: can't remove '/dev/pts': Device or resource busy
rm: can't remove '/dev': Directory not empty
rm: can't remove '/proc/swaps': Operation not permitted
rm: can't remove '/proc/kallsyms': Operation not permitted
rm: can't remove '/proc/dma': Operation not permitted

SNIP 881 entries

rm: can't remove '/proc/149/oom_adj': Permission denied
rm: can't remove '/proc/149': Operation not permitted
rm: can't remove '/proc': Device or resource busy
rm: can't remove '/tmp': Device or resource busy
rm: can't remove '/': Device or resource busy

    
por 20.07.2011 / 16:23
7

Lembro-me de ter sido mastigado em alt.sysadmin.recovery nos dias anteriores, quando não existia /proc e /dev era apenas um diretório regular contendo entradas para inodes inusitados ...

... mas, em algumas variantes do Unix (minha lembrança é HP-UX, mas isso pode estar totalmente errado), você poderia não remover a última entrada de diretório de um programa que estava sendo executado . (Bibliotecas compartilhadas? Quais são essas?)

Em tais sistemas, se você iniciou um no modo de manutenção (portanto, nada estava em execução, mas seu shell, nem mesmo init e nenhum sistema de arquivos secundário foi montado) e fez exec /bin/rm -rf / , você ficaria com um sistema de arquivos raiz completamente vazio exceto que /bin e /bin/rm sobreviveriam.

Os habitantes do monastério do diabo assustador consideraram isso adequado e apropriado.

    
por 21.07.2011 / 02:06
4

rm -rf / não deve ser permitido em implementações recentes, pois foi sugerido que viola o padrão POSIX:

" rm -rf / " proteção no blog da Oracle

Anyway, in the end, we got the spec modified, and Solaris 10 has (since build 36) a version of /usr/bin/rm (/bin is a sym-link to /usr/bin on Solaris) and /usr/xpg4/bin/rm which behaves thus:

[28] /bin/rm -rf /
rm of / is not allowed
[29] 
    
por 20.07.2011 / 17:58
3

Um ponto que eu não vi por outra pessoa: os arquivos que estão abertos no momento (por exemplo, rm propriamente dito), mesmo que excluídos, não vão realmente desaparecer do drive até serem fechados.

    
por 20.07.2011 / 19:12
1

Por ter tentado uma vez (em um servidor que está me irritando), logado como root, no terminal, você perderá quase tudo. A única coisa que não será apagada será apenas o processo que foi essencial para o SO.

    
por 20.07.2011 / 15:55
1

Até onde você pode chegar, depende basicamente das distribuições específicas do Unix / Linux.

Mas, para responder à sua pergunta básica, o comando sim - rm seria removido com ela, assim como qualquer outro comando padrão em /bin e outras pastas.

Aqui está o teste simples que eu fiz no Linux Ubuntu 15.04 usando VM.

  1. Inicialize a máquina virtual via vagrant :

    vagrant init ubuntu/vivid64 && vagrant up --provider virtualbox && vagrant ssh
    
  2. Então, quando você está tentando remover todos os arquivos da maneira padrão, ele não 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. Então, vamos tentar --no-preserve-root . Sempre verifique se você está logado na máquina virtual (então você está tendo vagrant@vagrant-ubuntu-vivid-64:~$ ), então execute (não tente isso em 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
    

    Depois disso, ele retorna ao prompt do shell como se nada tivesse acontecido, mas você não pode mais executar nenhum comando além de alguns embutidos e kill , para que você possa terminar seu trabalho e matar sua sessão:)

    Por exemplo:

    $ 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 isso, praticamente removemos tudo, incluindo rm , ls e todos os outros comandos, mas você ainda está logado. Existem algumas pastas especiais que não foram removidas, como alguns dispositivos de /dev , /proc ou /sys que não são diretórios / arquivos regulares, mas é pseudo sistema de arquivos fornecendo interfaces para processar e dados do kernel. / p>

Se você não tem Vagrant ou Linux, pode jogar com alguns emuladores JavaScript Linux x86 .

Se você estiver interessado em possibilidades de se recuperar de um desastre como esse, verifique:

por 27.09.2015 / 17:17