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

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 excluir tudo. Por curiosidade, o que acontece quando o kernel e /binsão excluídos? Como rmmantém uma pilha de tempo de execução? Como rmconsegue se comunicar com o sistema de arquivos e excluir completamente? Como ele se comunica com o hardware?

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

Barra lateral / atualização: De acordo com a resposta de David Hoelzer (e mencionada nos comentários), o inode para o qual o hardlink /bin/rmcostumava apontar permaneceria até o fim rm(porque o Linux está em estado aberto), mas esse fato é irrelevante; o estado do disco não importa.

O binário é carregado na memória antes de ser executado. Mesmo se você pudesse destruir manualmente os rmdados do disco, eles não afetariam ou impediriam a exclusão (supondo que você não torne o disco indisponível).

Não faço ideia do que é um inode ou hardlink? Esta é a resposta em que resolvi.

De qualquer forma, é também por isso que você pode excluir o pacote do kernel atual sem a implodiçã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 iria falhar depois /bin/rmmorreu porque ele chama de uma vez para cada nome de arquivo:

find / -exec rm {} \;

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

Eu não tentei esse 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-rootestava sendo executado em uma sessão raiz aberta diretamente na máquina, enquanto eu também estava conectado através sshde outra máquina, usando a conta raiz também.

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

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

ou:

rm: não é possível remover '/ ...': dispositivo ou recurso ocupado

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

Falha na leitura do soquete: redefinição de conexão por ponto

Na máquina, quatro diretórios permanecem:

• /dev. É aqui que os arquivos do dispositivo são armazenados.
• /proc- no sistema de arquivos em memória criado pelo kernel.
• /run, um local padronizado do sistema de arquivos 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 Tab, os nomes de diretórios e arquivos ainda sejam exibidos). Você pode cdem diretórios diferentes, e também echooutras coisas, mas comandos como catnão estão mais disponíveis.

Também não existe sudo.

shutdown -h nowe rebootdesapareceu também, então sua única opção parece desligar a máquina manualmente. Logout ( exit) não funciona, mesmo que mostre um bom texto de "logout".

Depois de tentar reiniciar a máquina, você recebe um bom erro 15 do GRUB e, em seguida, nada acontece; nesse momento, você pode começar a pensar que rmpode ter feito algo ruim no seu sistema.

Você pode fazer isso também

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 o benefício de tornar a experimentação realmente fácil. Como você está usando o Ubuntu, você pode estar interessado em vmbuilder . Essa é uma ferramenta que permite implantar máquinas virtuais em questão de minutos (a documentação oficial afirma que isso pode ser feito "em cerca de um minuto", mas o tempo real, mesmo em hardware rápido, é de cerca de dois a três minutos .

Depois que a implantação termina, você tem um ambiente com o qual pode brincar. Se você acabar destruindo, não importa: você implanta a máquina novamente e, dois minutos depois, pode continuar.

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

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

Essa experimentação não se limita ao próprio sistema operacional. Você pode fazer todo tipo de coisa envolvendo software. Tem um aplicativo suspeito? Teste-o em uma VM - se for um vírus, não fará nenhum mal. Deseja testar uma operação em um banco de dados, pois isso pode afetar o ambiente? Teste em uma VM.

E se você fizesse isso em uma máquina real, sem teste?

Coisas ruins acontecem. Observe que o rmprotege de si mesmo: rm -rf /não funcionará: você precisa usá-lo --no-preserve-root. Ainda assim, e se você realmente conseguiu, por engano, remover tudo?

rmapenas desassocia 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 apenas jogar fora seus discos rígidos com dados confidenciais quando eles não estiverem mais funcionando).

Isso significa que você só precisa ter um PC sobressalente com um compartimento de disco rígido para recuperar quase todos os arquivos. O importante é evitar gravar qualquer coisa no disco rígido para recuperar: os dados que você escreve sobrescreverão os arquivos desvinculados.

Conforme observado no artigo no comentário de 200_success , se você agir com inteligência, poderá recuperar a máquina mesmo sem um PC sobressalente. Se você se importa apenas com os dados, eu não me incomodaria - recuperá-los com um PC sobressalente é muito mais fácil.

O motivo é que a camada de nomeação de arquivos (com o que você vê ls) é realmente apenas para sua conveniência. O driver do sistema de arquivos e o kernel cuidam apenas do que é o inode. Quando um arquivo é referenciado por nome, ele é imediatamente convertido no 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 é uma unlink. O que está acontecendo sob o capô é que a contagem de links (o número de nomes de arquivos na camada de nomes de arquivos) apontando para o inode é diminuída. O sistema de arquivos sabe que um arquivo é excluído quando a contagem de links chega a zero.

Quando um arquivo é excluído, rmele 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 esta 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 /a entrada é excluída /bin/rm. O arquivo está aberto (existe um identificador de arquivo), mas o inode é marcado como excluído (contagem de links = 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 é, de certa forma, um arquivo muito bem oculto :). Para obter acesso, você teria que usar algo de baixo nível para referenciá-lo pelo número do inode, e não pelo nome (porque não há um) ou editar uma entrada de diretório para apontar para 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 para o inode de qualquer maneira. Vou deixar isso para você experimentar, se quiser. Claramente, porém, esses dois últimos levam o sistema de arquivos a estar em um estado inconsistente.

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

rmnão é apenas um comando. É um programa encontrado em PATH.

Portanto, o que acontece quando você executa é o seguinte:

• você chama (como root) rm -rf /
• instância do programa rmé carregada na memória com argumentos -rfe/
• com base nesses argumentos, o programa rminicia suas operações (passando por tudo em montado / partição e removendo recursivamente as referências a ele [desculpe pelo tecnicismo;)]))
• uma vez concluído, a instância do rmprograma é descarregada
• Neste ponto, as únicas coisas na memória são os programas que foram carregados anteriormente (por exemplo, bash se você tiver um terminal aberto no Ubuntu, ambiente de área de trabalho, kernel, drivers etc.)
• se você tentar chamar outro comando (que no caso do Linux o torna um programa independente), ele falhará porque não existe esse programa encontrado nos locais PATH (e os locais PATH não existem mais). No entanto, tudo depois de carregado ainda será executado

Apenas para entender como ele funciona, tente instalar o LAMP no ubuntu (no Virtualbox), algum cache de script e código de código PHP, e depois chame esse comando maligno. Surpreendentemente (se você tiver sorte o suficiente e seu cache do opcode não perceber a exclusão do arquivo php), você ainda poderá acessar scripts php de fora via apache webserver!

PS: esse comando maligno mesmo executado como root não exclui everything, não pode excluir alguns processos privilegiados do kernel /proce não pode excluir algumas coisas de /devdispositivos que aparecem no seu sistema como arquivos. De fato, a raiz não é tão onipotente quanto pensamos, o kernel, por outro lado, é.

PPS: Além disso, você ainda terá arquivos que estavam lockedem outro processo no momento da tentativa de exclusão.

Depois que tudo é apagado dos discos rígidos, o kernel ainda está funcionando, mas meio que travado, pois não há dispositivos e programas, comandos, etc.

O sistema operacional não funcionará mais.

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

Esteja ciente de que, se o sistema possui o selinux e o selinux está no modo de imposição, as políticas do selinux estão 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.

O Selinux é imposto no kernel; você teria que comprometer o kernel para contorná-lo.

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

As revisões posteriores do Android obrigaram o Selinux a aplicar apenas por esse motivo.