“chown -R root /” como eu estou ferrado?

Question

Eu acidentalmente executei o comando chown -R root / ao tentar alterar as permissões para a pasta pública do meu aplicativo de trilhos. Eu acreditava que isso mudou as permissões para todas as minhas pastas no diretório /. Então, minha pergunta é: quão perigoso é isso, na verdade, a melhor pergunta seria: existe alguma maneira de desfazer isso?

    

Answer 1

Uma maneira de atenuar o problema aqui (não resolver, mas ajudá-lo a sair de um buraco) é executar um processo em um sistema similar para coletar as propriedades apropriadas dos arquivos. Eu aprecio as chances de uma correspondência exata serem um pouco pequenas, mas se ambas as o / s estiverem no mesmo nível com pacotes similares instalados, você pode ter sorte.

Depois de coletar as permissões de arquivo em um arquivo, você pode executar um processo em seu próprio sistema para ler os arquivos e perms / ownerships do arquivo bom e substituí-los no seu. Eu tenho um par de pequenos aplicativos caseiros no Linux que fazem exatamente isso.

Por exemplo,

777*0*0*S*16*1334559119*1334532895*1361208513*/usr/lib32/*libgomp.so.1
644*0*0*F*67370*1359536382*1359374461*1359717843*/usr/lib32/*librt.a
644*0*0*F*59044*1334559119*1334532931*1355405098*/usr/lib32/*libgomp.so.1.0.0
644*0*0*F*1238*1359536382*1359374461*1359717843*/usr/lib32/*libBrokenLocale.a
777*0*0*S*17*1359536382*1359374460*1361208513*/usr/lib32/*libdl.so
644*0*0*F*905712*1334559116*1334533011*1355405098*/usr/lib32/*libstdc++.so.6.0.16
777*0*0*S*15*1333306601*1323929512*1361208513*/usr/lib32/*libbz2.so.1.0
777*0*0*S*24*1359536382*1359374460*1361208513*/usr/lib32/*libnss_files.so
644*0*0*F*1128*1359536382*1359374462*1359717843*/usr/lib32/*crt1.o

RWX * UID * GID * outras coisas * diretório * nome do arquivo

    

Answer 2

Primeiro, pare o comando se ainda estiver em execução!

Agora tudo vai pertencer à raiz e isso é bastante problemático.

Você deve tentar restaurar informações de seu último backup.

Também é importante não reiniciar o sistema antes de verificar todos os aplicativos em execução e o usuário iniciá-los na inicialização. Se você fizer isso, alguns deles podem não iniciar corretamente devido a problemas de permissão.

Boa sorte.

    

Answer 3

Muito e não é bem assim.

"Muito", no sentido de que, se o comando tiver realmente passado, sua segurança estará estragada. Você agora não sabe quais caminhos têm quais proprietários e quem deve ter permissão para fazer o quê.

"Não exatamente" no sentido - você tem certeza de que era root quando fez isso e o comando foi até o fim? Se você cancelou, assim que você viu, então você pode ter sorte e o reparo pode ser baixo. Se você não fosse root, este comando não deveria ter sido capaz de fazer isso, a menos que você tenha feito algo como sudo ... .

Não há remédio único para isso. Se você tiver um backup, poderá restaurá-lo. Pode ser necessário verificar as propriedades no backup e aplicá-las. Se você estiver usando um verificador de rootkit (digamos rkhunter), ele pode ter uma lista das propriedades mais básicas e possivelmente consertá-lo. (Não é bem provável).

    

Answer 4

No Fedora, pelo menos, o comando RPM tem as opções --setperms e --setugids , usando aquelas que você pode corrigir a maioria dos arquivos de propriedade do sistema, como rpm --setugids -a . Para (de certa forma) corrigir os arquivos para cada usuário, você pode fazer por cada um chown -R user /home/user . Provavelmente haverá sobras que não foram corrigidas pelo acima, particularmente se você tiver algum tipo de servidor (web, ftp, outros), eles terão que ser manipulados um por um.

Provavelmente outras distribuições possuem mecanismos semelhantes. Ou faça uma atualização completa (ou seja, instale tudo de novo, como se estivesse de alguma forma danificado. OK, foi danificado).

[Sim, isso é mais uma vez uma maneira cruel e Unix de ensinar os usuários desavisados a considerar cada comando cuidadosamente antes de pressionar ENTER, e usar root moderadamente . Considere-se ensinado.]

    

Answer 5

Se o seu uso do OSX Apple fornece um recurso de restauração dentro dos Utilitários de Disco para corrigir esse problema. Se você estiver usando uma distribuição Linux, estou certo de que você terá que refazer todas as permissões manualmente. Em qualquer um dos casos, dê um tapa nas suas mãos e não faça isso de novo

    

Answer 6

Infelizmente, não sei de como desfazê-lo, mas você provavelmente pode deixar os arquivos do sistema como de propriedade do root e restaurar todos os arquivos em seu $ HOME de sua propriedade (e fazer o mesmo para todos usuários do sistema). Nesse ponto, você pode corrigir permissões e / ou proprietário em cada arquivo que não esteja no diretório $ HOME e que precisar dele conforme for apresentado. Sim, isso é uma dor, mas não acho que haja uma solução fácil. Isso é o que eu faria de qualquer maneira.

    

Answer 7

Eu diria que você está muito "ferrada" como você diz. A melhor maneira (e mais eficiente) é reinstalar e restaurar itens críticos de seus bons backups. Desculpe esta não é uma situação que geralmente tem uma solução rápida com um final feliz. Boa sorte!