Por que o terrível 'rm -rf /' é permitido? [fechadas]

Question

Todos conhecemos o poder destrutivo do seguinte comando executado como root:

rm -rf /

Perguntas relacionadas:

• Até onde você vai chegar com um 'rm -rf / 'comando?
• excluindo tudo: # rm -rf /

Não consigo ver quando essa combinação específica de parâmetros seria útil, pois destrói todo o sistema e há maneiras mais eficientes de fazer isso. O comando rm poderia verificar esses parâmetros específicos e implementar algum tipo de proteção - peça confirmação no mínimo, apesar do parâmetro -f .

Por que não existe tal salvaguarda no comando rm ?

Estou ciente de que você deve ser extremamente cuidadoso ao executar comandos como root. Com grande poder (...) . No entanto, esse caso específico não deveria ser uma exceção a essa regra?

    

Answer 1

Depende da distribuição. O Linux mais antigo que estou agora permite (eu acho, não testei :-)) e declara em man rm :

   --no-preserve-root do not treat '/' specially (the default)

   --preserve-root
          fail to operate recursively on '/'

Em muitas distribuições recentes, você precisa adicionar explicitamente --no-preserve-root para desativar a proteção. Caso contrário, ele não será executado.

Em relação ao Ubuntu, veja este problema onde esse comportamento é discutido.

A história dessa proteção de acordo com Wikipedia :

Sun Microsystems introduced rm -rf / protection in Solaris 10, first released in 2005. Upon executing the command, the system now reports that the removal of / is not allowed. Shortly after, the same functionality was introduced into FreeBSD version of rm utility. GNU rm refuses to execute rm -rf / if the --preserve-root option is given, which has been the default since version 6.4 of GNU Core Utilities was released in 2006.

    

Answer 2

Why is there no such safeguard in the rm command?

Já existem três salvaguardas:

• A opção -r , sem a qual um diretório não pode ser removido.
• A opção -i , que verifica se você realmente deseja excluir o que foi solicitado a excluir. O aliasing rm to rm -i ativa essa proteção, a menos que você adicione a opção -f para desativá-la.
• Propriedade de arquivo, que impede que todos os usuários, mas root , excluam o diretório raiz.

O conjunto de ferramentas Unix é como uma motosserra: foi projetado para fazer coisas muito poderosas e ser usado por pessoas que entendem o que estão fazendo. Aqueles que caminham negligentemente tendem a acabar se ferindo. Isso não quer dizer que os experientes não cometam erros e, obviamente, a Sun e outras pessoas acham que os usuários com root precisam ser protegidos de si mesmos.

However shouldn't this specific case be an exception to that rule?

As pessoas perguntam por que não podemos colocar um protetor de lâmina sobre a motosserra rm desde pelo menos a década de 1980. (Provavelmente mais, mas minha história com o Unix não volta mais longe que isso.) Você precisa se fazer mais perguntas:

• Como estamos adicionando exceções, o que mais deve ser considerado sagrado? Devemos evitar a exclusão recursiva de qualquer coisa no diretório raiz para evitar erros igualmente devastadores como rm -rf /* ? E quanto ao diretório pessoal do usuário? E quanto a /lib ou /bin ? Teríamos que ter uma versão especial de rm para evitar esses erros em sistemas com um layout de sistema de arquivos não tradicional?

• Onde colocamos a aplicação dessas proibições? Apenas em rm ou damos ao kernel esse trabalho? Como rm na verdade não exclui nada (faz muitas chamadas para unlink(2) e rmdir(2) com base nos argumentos), não haveria como o kernel detectar que rm estava realmente buscando / até o momento realmente veio para excluí-lo. Como a única chamada para rmdir(2) que seria bem-sucedida é quando o diretório de destino está vazio, alcançar esse ponto com / significaria que o sistema já foi feito.