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


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

Pergunta bônus: Após o comando ter sido executado, rm se removeu?

Atualizar: 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, eu acredito que o BusyBox tem sua própria versão e não permite que você remova tanto quanto você poderia potencialmente.

Esta questão foi uma Pergunta de super usuário da semana.
  Leia o 7 de julho de 2011 entrada de blog para mais detalhes ou envie seu próprio Pergunta da semana.


200


origem


É engraçado que você tenha feito essa pergunta. Eu estava apenas respondendo a outra questão em outro fórum e comecei a lembrar de um artigo que li há algum tempo. Felizmente eu salvei para momentos como este: A história clássica de terror do Unix Além do fato de que é interessante ver até onde isso vai ... Eu acho que é um artigo muito bem escrito e é geralmente uma boa leitura! - akseli
Eu apenas tentei sudo rm -rf / no tinycore / microcore linux e parece que o sistema operacional protege vários diretórios (/ sys e outros) de serem excluídos. - n0pe
eu tentei rm -f /bin/rm uma vez. Infelizmente, funcionou, e passei a próxima hora recebendo a versão correta do rm de volta do GNU coreutils. - squircle
Espere um segundo, vou tentar ... - Martijn Courteaux
Eu faço isso na loja da Apple o tempo todo - eggie5


Respostas:


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).

Você pode substituir essa proteção --no-preserve-root. rm Em seguida, irá remover tudo o que for possível, sem parar depois de ter tentado remover todos os arquivos. Claro que não vai remover sistemas de arquivos virtuais como /proc e /sys, mas isso é irrelevante - removerá tudo no seu 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 irá falhar na próxima vez.


188



Exatamente o que eu estava procurando. Agora, para usar este poder para tomar o mundo. - n0pe
+1 especialmente para --no-preserve-root porque isso geralmente não é mencionado. - Matěj G.
@MaxMackie, é importante notar que os hackers descobriram rapidamente que este era o menos coisa útil que eles poderiam fazer para um usuário. Ele destrói todos os dados que podem ser usados ​​para ganhos em dinheiro e impede que o hacker explore mais a máquina. Como um gato com um inseto, você não quer matá-lo, você só quer brincar com ele por um tempo porque é divertido. - zzzzBov
Para responder a outra questão do OP, sim, o rm será removido. É totalmente possível modificar ou excluir um executável mesmo quando há uma instância dele em execução. Ele continuará funcionando também e não será afetado pela alteração. - thomasrutter
Eu gostaria de mencionar "chmod -R user: user *" em /, porque também é um erro recursivo e caro. Eu fiz isso uma vez e tinha meio caminho em casa quando eu podia abortar. / bin / boot / etc / dev eram de propriedade. Felizmente, o servidor continuou funcionando enquanto eu passava as próximas horas manualmente e redefinindo as propriedades de um sistema de referência. No entanto, ninguém mais poderia usar su ou sudo depois. Eventualmente descobriu que / bin / su não tinha mais seu setuid bit set. Tome nota para o futuro: chowning / bin / su reseta seu bit setuid! - Andy Lee Robinson


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

Executando o rmrf no Linux (vídeo)

Pontos de bônus se você puder nomear os processos conforme eles começam a morrer.


41





Configurar uma VM e tentar por diversão?

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

Se você deixá-lo ir, o sistema operacional será muito além da recuperação, embora você possa obter alguns dados de volta facilmente.

De qualquer forma, você estará querendo fazer uma reinstalação do sistema operacional.


22



Eu nem sequer pensei em tentar em uma VM. Indo tentar agora! ooo isso é divertido. - n0pe
Equivocadamente escreve o comando no terminal do sistema host - slhck
Confira o artigo que eu postei. "A clássica história de terror do Unix!" - akseli
Estou no trabalho agora e não tenho tempo para passar por uma instalação completa de uma distro popular (ubuntu / slack / suse / fedora). Se alguém mais puder clonar um arquivo de disco da VM e testá-lo para nós, seria incrível. - n0pe
Com o Amazon EC2, ele deve ser rápido para acionar um de seus AMIs que já tenham o linux instalado e disparar ... - David d C e Freitas


Bem, experimentando http://bellard.org/jslinux/ produz:

rm: não é possível remover '/ dev / pts': dispositivo ou recurso ocupado
  rm: não é possível remover '/ dev': diretório não vazio
  rm: não é possível remover '/ proc / swaps': operação não permitida
  rm: não é possível remover '/ proc / kallsyms': operação não permitida
  rm: não é possível remover '/ proc / dma': operação não permitida

Entradas SNIP 881

rm: não é possível remover '/ proc / 149 / oom_adj': permissão negada
  rm: não é possível remover '/ proc / 149': operação não permitida
  rm: não é possível remover '/ proc': dispositivo ou recurso ocupado
  rm: não é possível remover '/ tmp': dispositivo ou recurso ocupado
  rm: não é possível remover '/': dispositivo ou recurso ocupado


11



Sim eu recebo esses erros / avisos também. É este padrão que você pensa? - n0pe
/ proc, / sys, as vezes / dev e quaisquer pontos de montagem são propriedades do sistema operacional e não podem ser excluídos. - pjc50
Concorrendo com o @ pcj50, esses arquivos não são literalmente no disco rígido, portanto, "excluí-los" não é significativo. - CarlF


Eu me lembro disso sendo mastigado alt.sysadmin.recovery de volta nos dias de outrora, quando não havia tal coisa /proce /dev era apenas um diretório regular contendo entradas para um monte de inodes incomuns ...

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

Em tais sistemas, se você iniciou um em modo de manutenção (então nada estava rodando, mas seu shell, nem mesmo inite nenhum sistema de arquivos secundário foi montado) e exec /bin/rm -rf /, você ficaria com um sistema de arquivos raiz completamente vazio exceto aquele /bin e /bin/rm iria sobreviver.

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


7





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

De qualquer forma, no final, temos a especificação modificada e o Solaris 10 tem (desde a versão 36) uma versão do / usr / bin / rm (/ bin é um link sym para / usr / bin no Solaris) e / usr / xpg4 / bin / rm que se comporta assim:

[28] /bin/rm -rf /
rm of / is not allowed
[29] 

4



"salientando que, se alguém tentar remover" / "de forma recursiva, a pessoa tentará finalmente remover" .. "e". ", e que tudo o que estamos fazendo é permitir que a empresa pré-determine isso heuristicamente. ! "- er, isso não impede a remoção qualquer diretório? A especificação real só proíbe .. e. nos argumentos reais da linha de comando, ele não diz nada sobre o que você "finalmente tenta remover" - Random832
Por que não permitiria a remoção de qualquer diretório? O diretório raiz é o único preocupado aqui e removê-lo obviamente implica em remover "." e "..", qualquer que seja o diretório atual. O senso comum não é proibido na interpretação padrão. - jlliagre
Essa linha de argumentação é pura genialidade. - Nate C-K
O padrão especifica que rm não pode continuar se um argumento tiver a string "." ou ".." como o componente de nome de base. Você não pode remover /foo/.. mesmo que você não esteja /foo. Faz não especifique que você não tem permissão para remover o diretório atual (por exemplo, rm -r `pwd`) ou o pai do diretório atual. - Random832
Na verdade, eu não entendi a afirmação e você está correto. Esperançosamente, os caras padrão aceitaram o comportamento mais inteligente como sendo compatível com o padrão. A remoção de partes grandes, se não de todo o sistema de arquivos, tornaria o SO não compatível com o padrão rapidamente. - jlliagre


Um ponto que eu não vi foi criado por mais ninguém: os arquivos que estão abertos no momento (por exemplo, rm propriamente dito), mesmo que excluídos, não desaparecerão da unidade até serem fechados.


3



Isso mesmo, porque eles estão carregados na memória, certo? - n0pe
Não tenho certeza se isso é seguro assumir; o kernel poderia muito bem apenas carregar o arquivo removido na memória e removê-lo no disco imediatamente, e manter essa cópia na memória até que o arquivo seja aberto (por exemplo, até a execução do rm). - Ambroz Bizjak
Eu não estou especulando. Se um programa está em execução, excluí-lo não o remove nas minhas caixas do Linux, pelo menos. (Lembre-se que eu não testei isso em alguns anos.) - CarlF
rm  vai remova-se do fs - o programa está completamente carregado na memória, não no Arquivo - warren
@MaxMackie: não porque eles estão carregados na memória, mas porque uma referência de arquivo aberto tem o mesmo poder de um link físico (ou seja, se um arquivo tiver pelo menos um link físico, ele não será excluído do disco). - Lie Ryan


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


1



"[não apagado] apenas o processo que era essencial para o sistema operacional" - oh, não se preocupe. Ao contrário do Windows, o Linux irá apagar qualquer coisa, mesmo que o arquivo seja crítico ao sistema operacional. e em uso. /boot, /sbin, /etc, /bin, /vmlinuz? Bam se foi. Boa sorte de arrancar sem eles - na verdade, boa sorte qualquer coisa em tudo uma vez que a exclusão é concluída. - Piskvor
Se eu me lembro, havia algum arquivo que não foi excluído e deixei meu linux rodar por mais de 4 horas. Mas ainda assim, é bom saber o que acontece, como fazer um chmod 777 / * -fR;) - Anarko_Bizounours
"chmod 777 / * -fR" - Isso deve deixar o sistema muito inseguro, mas muito fácil de usar. - Bart van Heukelom
fez isso, é muito inseguro. Você não pode fazer nada, algum processo precisa ter certo específico, e o chmod 777 vai mudar todo direito, você nunca poderá carregar uma sessão, e algum processo para. - Anarko_Bizounours
@BartvanHeukelom, algumas ferramentas executarão um rápido autoteste ou serão testadas pelo sistema para apropriação e permissões adequadas e se recusarão a agir se configuradas incorretamente. - killermist


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

Mas para responder sua pergunta básica, sim - rm comando seria removido com ele, bem 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 novamente que você está logado na máquina virtual (então você está tendo vagrant@vagrant-ubuntu-vivid-64:~$), em seguida, 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, então você pode 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.
    

Então isso removeu tudo, inclusive 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.

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

Se você estiver interessado em possibilidades de se recuperar de tal desastre, verifique:


1