Como o 'rm -rf /' pode deletar todos os arquivos no sistema?

Question

Eu não tentei este comando no Ubuntu (por razões óbvias), então não tenho certeza se o Ubuntu permitirá sua execução. Mas é famoso por deletar tudo. Apenas por curiosidade, o que acontece quando o kernel e /bin são excluídos? Como o rm mantém uma pilha de tempo de execução? Como o rm consegue se comunicar com o sistema de arquivos e concluir a exclusão? Como se comunica com o hardware?

    

Answer 1

Não importa que /bin/rm seja excluído. Ele está sendo executado apenas uma vez e, nesse ponto, tudo é carregado na memória, assim como todo o restante necessário para continuar enviando exclusões para o sistema de arquivos e o disco.

Barra lateral / Atualização: Por resposta de David Hoelzer (e mencionada nos comentários), o inode do hardlink /bin/rm usado para apontar permaneceria até rm finished (porque o Linux mantém em um estado aberto) mas esse fato é irrelevante; o estado do disco não importa em nada.

O binário é carregado na memória antes de ser executado. Mesmo se você pudesse destruir manualmente os dados do disco rm , isso não afetaria ou impediria a exclusão de concluir (supondo que você não disponibilize o disco).

Não tem ideia do que é um inode ou hardlink? Esta é a resposta onde eu trabalhei.

De qualquer forma, também é por isso que você pode deletar o pacote para o kernel atual sem a implosão do computador. Contanto que você instale uma versão diferente, ela poderá inicializar.

Novamente, isso funciona porque rm é chamado apenas uma vez. O seguinte falharia após /bin/rm ter morrido porque o chama uma vez para cada nome de arquivo:

find / -exec rm {} \;

Dito isso, find / -exec rm -rf {} + e find / -print0 | xargs -0 rm -rf também provavelmente falharão porque ambos têm limites de argumento, o que significa que eles excluiriam apenas alguns arquivos antes de serem chamados novamente. Em algum momento ao longo da jornada, /bin/rm poderia expirar ( e ser liberado) antes que o restante dos arquivos fosse excluído. Não é garantido embora. Se /bin/ fosse o último diretório digitado, esses métodos poderiam funcionar.

    

Answer 2

  

Eu não tentei este comando no Ubuntu (por razões óbvias), então não tenho certeza se o Ubuntu permitirá sua execução.

eu fiz. rm -rf / --no-preserve-root estava rodando em uma sessão raiz aberta diretamente na máquina, enquanto eu também estava conectado através de ssh de outra máquina, usando a conta root também.

O que acontece é que você começa a receber muito mensagens como:

  

rm: não é possível remover '/ ...': operação não permitida

ou:

  

rm: não pode remover '/ ...': dispositivo ou recurso ocupado

Surpreendentemente, ssh conexão permaneceu aberta até o final da operação. Foi só quando fechei a conexão e tentei reabri-la que apareceu um erro:

  

Falha na leitura do soquete: conexão redefinida pelo peer

Na máquina, quatro diretórios permanecem:

• /dev . É aqui que os arquivos do dispositivo são armazenados.
• /proc - sistema de arquivos na memória criado pelo kernel.
• /run , um local de sistema de arquivos padronizado para daemons.
• /sys . Isso permite que você obtenha informações sobre o sistema e seus componentes.

Isso significa que não resta muito, e não há muito o que fazer lá. Você não pode ls (embora ao usar o Tab , os nomes dos diretórios e arquivos ainda sejam exibidos). Você pode cd em diretórios diferentes e também echo stuff, mas comandos como cat não estão mais disponíveis.

Não há sudo .

shutdown -h now e reboot desapareceram também, então sua única opção parece desligar a máquina manualmente. O logout ( exit ) não funciona, mesmo que mostre um texto "logout" legal.

Uma vez que você tenta reinicializar a máquina, você recebe um bom erro 15 do GRUB, e nada acontece, e nesse ponto você pode começar a pensar que seu rm poderia ter feito algo ruim ao seu sistema. / p>

Você também pode fazer isso

Não, espere, não faça isso na sua máquina!

O que você pode fazer é executar uma máquina virtual . As VMs têm a vantagem de tornar a experimentação realmente fácil. Como você está usando o Ubuntu, talvez esteja interessado no vmbuilder . Esta é uma ferramenta que permite implantar máquinas virtuais em questão de minutos (a documentação oficial alega que isso pode ser feito "em cerca de um minuto", mas o tempo real, mesmo em hardware rápido, é de cerca de dois ou três minutos .

Quando a implantação terminar, você terá um ambiente em que poderá brincar. Se você acabar destruindo, não importa: você implanta a máquina novamente e, dois minutos depois, você pode continuar.

Se você usa um software como o VMWare, talvez também esteja interessado em snapshots (observe que o VMWare Player gratuito não possui esse recurso; você deve adquirir o VMware Workstation). Observe que o Hyper-V é gratuito e suporta instantâneos (mas você precisa executar o Windows).

O benefício dos instantâneos é que você pode tirar um em questão de milissegundos. Retroceder para um instantâneo demora mais, mas geralmente é uma questão de segundos. Isso torna a experimentação ainda mais fácil e rápida.

Esta experimentação não está limitada ao próprio sistema operacional. Você pode fazer todo tipo de coisas envolvendo software. Tem uma aplicação suspeita? Teste em uma VM - se for um vírus, não causará nenhum dano. Quer testar uma operação em um banco de dados, uma vez que isso pode afetar o ambiente? Teste em uma VM.

E se você fez isso em uma máquina real, sem testes?

Coisas ruins acontecem. Observe que rm protege você de si mesmo: rm -rf / não funciona: você precisa usar --no-preserve-root . Ainda assim, e se você realmente conseguisse, por engano, remover tudo?

rm somente desativa arquivos , mas os dados ainda estão lá, no seu disco rígido. Isso torna possível recuperá-lo mais tarde (e é por isso que você não deve simplesmente descartar seus discos rígidos com dados confidenciais quando eles não estiverem mais funcionando).

Isso significa que você só precisa ter um PC reserva com um gabinete de disco rígido para realmente recuperar quase todos os arquivos todos . O importante é evitar escrever qualquer coisa no disco rígido para recuperar: os dados que você escrever substituirão os arquivos desvinculados.

Como observado pelo artigo no comentário do 200_success , se você agir de maneira inteligente , você pode recuperar a máquina mesmo sem um PC de reserva Se você se importa apenas com dados, eu não me incomodaria - recuperá-la com um PC sobressalente é muito mais fácil.

    

Answer 3

O motivo é que a camada de nomenclatura de arquivos (o que você vê com ls ) é realmente apenas para sua conveniência. O driver do sistema de arquivos e o kernel preocupam-se apenas com o inode. Quando um arquivo é referenciado por nome, ele é imediatamente traduzido para o inode, que contém todos os metadados, incluindo as permissões, os blocos de dados no disco, o ID do proprietário, o ID do grupo e a contagem de links.

A contagem de links é o que realmente importa aqui. Quando você exclui um arquivo em um sistema UNIX, a chamada real do sistema é um unlink . O que está acontecendo sob o capô é que a contagem de links (o número de nomes de arquivos na camada de nomenclatura de arquivos) apontando para esse inode é decrementada. O sistema de arquivos sabe que um arquivo é excluído quando a contagem de links chega a zero.

Quando um arquivo é excluído por rm , ele também edita o arquivo de diretório (sim, é apenas um arquivo que contém o nome do arquivo e o inode, além de alguns outros bits que não são importantes para essa resposta). No entanto, é a desvinculação que realmente libera os recursos do disco.

Isso leva a alguns outros efeitos interessantes. Primeiro, é possível ter um arquivo aberto cuja contagem de links é zero. Isso acontece quando rm -rf / exclui a entrada para /bin/rm . O arquivo está aberto (existe um identificador de arquivo para ele), mas o inode está marcado como excluído (link count = 0). Os recursos de disco não serão liberados e reutilizados até que o identificador de arquivo seja fechado.

Outro efeito interessante é o que acontece quando você tem um inode com uma contagem de links maior que zero, mas nada na camada de nomenclatura de arquivos que aponta para ele. Este é, em certo sentido, um arquivo muito bem escondido :). Para ter acesso a ele, você teria que usar algo de baixo nível para referenciá-lo pelo número de inode em vez de pelo nome (porque não há um) ou editar uma entrada de diretório para apontar o inode usando um editor hexadecimal.

Um terceiro efeito interessante é o que acontece se você reduzir a contagem de links para zero, mas apontar uma entrada de diretório no inode de qualquer maneira. Vou deixar isso para você experimentar se quiser. Claramente, porém, esses dois últimos levam a que o sistema de arquivos esteja em um estado inconsistente.

    

Answer 4

As respostas anteriores são boas, mas quero esclarecer um detalhe:

rm não é apenas um comando. É um programa que é encontrado em PATH .

Portanto, o que acontece quando você executa está seguindo:

• você chama (como root) rm -rf /
• instância do programa rm é carregada na memória com argumentos -rf e /
• com base nesses argumentos programa rm inicia suas operações (passando por tudo em montado / partição e recursivamente removendo referências a ele [desculpe por tecnicismo;)])
• assim que terminar, a instância do programa rm será descarregada
• neste ponto, as únicas coisas na memória são os programas que foram carregados lá anteriormente (por exemplo, bash se você tem terminal aberto no Ubuntu, ambiente Desktop, kernel, drivers etc)
• se você tentar chamar qualquer outro comando (que no caso do Linux o torna um programa autônomo), ele falhará porque não existe tal programa encontrado nos locais PATH (e os locais PATH não existem mais). No entanto, tudo que for carregado uma vez ainda será executado

Apenas para entender como funciona, tente instalar o LAMP no ubuntu (no Virtualbox), algum script e cache PHP opcode, então chame esse comando maligno. Surpreendentemente (se você tiver sorte o suficiente e seu cache opcode não notará a exclusão do arquivo php) você ainda pode acessar os scripts php de fora via servidor web apache!

PS: este comando maligno foi executado como root não excluirá everything , ele não pode excluir alguns processos com privilégios do kernel de /proc e não pode excluir alguns dos dispositivos /dev que aparecem no sistema como arquivos. De fato, a raiz não é tão onipotente quanto pensamos, o kernel, por outro lado, é.

PPS: Além disso, como um segundo pensamento, você ainda terá arquivos que foram locked por outro processo no momento da tentativa de exclusão.

    

Answer 5

Uma vez que tudo é apagado dos discos rígidos, o kernel ainda está funcionando, mas está preso, já que não existem dispositivos, programas, comandos, etc.

O sistema operacional não funciona mais.

E é verdade o que Oli diz, o comando é carregado / executado na memória e nada irá pará-lo a menos que você mate esse processo (claro, se o comando kill ainda estiver presente ^^).

    

Answer 6

Por favor, esteja ciente que se o sistema tiver selinux e o selinux estiver em modo enforcing, e as políticas do selinux estiverem configuradas corretamente; então nada vai acontecer.

O Selinux é um controle de acesso obrigatório, o que significa, entre muitas coisas, que o usuário root realmente não tem muito mais poder para destruir o sistema do que qualquer outro usuário no sistema.

Selinux é aplicado no kernel; você teria que comprometer o kernel para contornar isso.

Em um sistema bem projetado com boas políticas da Selinux, o root não seria capaz de fazer muito no sistema.

As revisões posteriores do Android têm a aplicação do Selinux apenas por este motivo.