Primeiro de tudo, uma terminologia secundária nitpick: chmodnão remove permissões. Ele MUDA -los.
Agora, a questão principal - o modo 777significa "Qualquer pessoa pode ler, escrever ou executar este arquivo" - Você deu permissão para que alguém faça (efetivamente) o que quiser.
Agora, por que isso é ruim?
- Você acabou de deixar todos lerem / modificarem todos os arquivos no seu sistema.
- Dê um beijo de despedida na segurança da senha (qualquer um pode ler o arquivo shadow e decifrar suas senhas, mas por que se preocupar? Apenas MUDE a senha! É muito mais fácil!).
- Dê adeus à segurança dos seus binários (alguém pode simplesmente escrever um novo
loginprograma que os permita entrar sempre).
- Dê um beijo de despedida nos seus arquivos: um usuário direciona mal
rm -r /e tudo acabou. Foi dito ao sistema operacional para deixá-los fazer o que quisessem!
- Você irritou todos os programas que verificam as permissões nos arquivos antes de iniciar.
sudo,, sendmaile muitos outros simplesmente não iniciam mais. Eles examinarão as principais permissões de arquivo, verificarão que não são o que deveriam ser e retrocederão uma mensagem de erro.
Da mesma forma, ssheles quebram horrivelmente (os arquivos-chave devem ter permissões específicas, caso contrário, são "inseguros" e, por padrão, o SSH se recusará a usá-los.)
- Você eliminou os bits setuid / setgid dos programas que os possuíam.
O modo 777é realmente . Entre as coisas em que liderar dígitos são o e pedaços.
A maioria dos programas que são setuid / setgid tem esse bit definido porque eles devem ser executados com certos privilégios. Eles estão quebrados agora.0777setuidsetgid
- Você quebrou
/tmpe/var/tmp
a outra coisa naquele dígito octal inicial que foi zerado é o sticky bit- Aquilo que protege os arquivos /tmp(e /var/tmp) de serem excluídos por pessoas que não os possuem.
(Infelizmente) existem muitos scripts mal comportados por aí que "limpam" fazendo um rm -r /tmp/*, e sem o bit fixo definido, /tmp você pode dar adeus a todos os arquivos desse diretório.
O desaparecimento dos arquivos de rascunho pode realmente incomodar alguns programas mal escritos ...
- Você causou estragos em
/dev /procsistemas de arquivos similares
Este é mais um problema nos sistemas Unix mais antigos, onde /devé um sistema de arquivos real, e o material que ele contém são arquivos especiais criados mknod, pois as alterações nas permissões serão preservadas durante as reinicializações, mas em qualquer sistema alterar as permissões do dispositivo pode causar problemas substanciais, desde os óbvios riscos à segurança (todos podem ler todos os TTY) até as causas menos óbvias em potencial de um pânico no kernel.
Credit to @Tonny for pointing out this possibility
- Soquetes e tubulações podem quebrar ou apresentar outros problemas Os
soquetes e tubulações podem quebrar completamente ou ser expostos a injeção mal-intencionada como resultado de serem graváveis no mundo.
Credit to @Tonny for pointing out this possibility
- Você fez todos os arquivos em seu sistema executável
Um monte de pessoas têm .em sua PATHvariável de ambiente (você não deve!) - Isto poderia causar uma surpresa desagradável como agora qualquer um pode soltar um arquivo convenientemente chamado como um comando (por exemplo make, ou ls, e tem a chance de fazer com que você execute o código malicioso.
Credit to @RichHomolka for pointing out this possibility
- Em alguns sistemas
chmod, as ACLs (listas de controle de acesso) serão redefinidas.
Isso significa que você pode ter que recriar todas as suas ACLs, além de corrigir permissões em todos os lugares (e é um exemplo real do comando destrutivo).
Credit to @JamesYoungman for pointing out this possibility
As partes do sistema que já estão em execução continuarão em execução? Provavelmente, por um tempo, pelo menos.
Mas na próxima vez em que você precisar iniciar um programa, reiniciar um serviço, ou proibir de reiniciar a caixa, você terá um mundo de mágoa, pois os itens 2 e 3 acima criarão suas cabeças feias.