Como redefinir as permissões de pasta para seu padrão no Ubuntu?

18

Eu recentemente digitei o comando

sudo chmod 777 -R /

depois disso, algumas coisas como

sudo -i

não estão funcionando normalmente. Então, eu estou querendo saber se existe alguma maneira que eu poderia redefinir as permissões de pasta para o seu estado original?

    
por Braiam 20.04.2010 / 11:36

6 respostas

17

É possível voltar desta situação confusa.

Eu corri novamente o mesmo tipo em questão (algum bug em um script que eu estava escrevendo) e resolvi isso, mas você precisa pedir ajuda a algum especialista. Seja muito cauteloso!

Primeiro, minha situação foi mais fácil de resolver porque eu tinha um sistema dual boot (Ubuntu e minha antiga instalação do Fedora), mas rodar o sistema operacional de um CD / DVD ou uma chave USB deveria fazer a mesma coisa.

MPOINT=/mount/ubuntu

Primeiro montei meus sistemas de arquivos assim (não esqueça de criar os pontos de montagem):

mount /dev/ubuntu/root $MPOINT
mount /dev/ubuntu/home $MPOINT/home

Então eu executei o seguinte comando (meu problema era apenas em alguns - diretórios críticos) para copiar as permissões do sistema em execução para o bagunçado (na verdade, no meu caso, eu instalei um sistema Ubuntu no Virtual Caixa sob fedora e tem as permissões lá):

find /etc /usr /bin /sbin -exec stat --format "chmod %a \"${MPOINT}%n\"" {} \; > /tmp/restoreperms.sh

E então eu executei o script restoreperms.sh.

Eu pude novamente inicializar no Ubuntu.

O conteúdo de restoreperms.sh será algo como:

(...)
chmod 755 /mount/ubuntu//etc/ppp
chmod 755 /mount/ubuntu//etc/ppp/ipv6-up
chmod 2750 /mount/ubuntu//etc/ppp/peers
chmod 640 /mount/ubuntu//etc/ppp/peers/provider
chmod 755 /mount/ubuntu//etc/ppp/ipv6-up.d
chmod 777 /mount/ubuntu//etc/ppp/resolv.conf
(...)

Eu não testei, mas também deve funcionar para proprietários e grupos de proprietários. Algo como:

find /etc /usr /bin -exec stat --format 'chown %U:%G ${MPOINT}%n' {} \; > /tmp/restoreperms.sh^

(...)
chown root:root /mount/ubuntu//etc/obex-data-server/imaging_capabilities.xml
chown root:root /mount/ubuntu//etc/obex-data-server/capability.xml
chown root:dip /mount/ubuntu//etc/ppp
chown root:root /mount/ubuntu//etc/ppp/ipv6-up
chown root:dip /mount/ubuntu//etc/ppp/peers
chown root:dip /mount/ubuntu//etc/ppp/peers/provider
chown root:root /mount/ubuntu//etc/ppp/ipv6-up.d
chown root:root /mount/ubuntu//etc/ppp/resolv.conf
(...)

É claro que você deve tomar cuidado aqui, que o UID e o GID são os mesmos em ambos os sistemas, mas para os usuários e grupos relacionados ao sistema, isso não deve ser um problema.

Editar:

Além disso, configurar o proprietário anulará os flags do SGID e SUID , o que causa problemas estranhos (por exemplo, você não poderá executar o sudo a menos que a permissão seja 4755). Você deve e deve definir apenas as permissões DEPOIS proprietários da configuração. SALVAR informações completas sobre permissão de arquivos junto com as informações do proprietário.

Rk:

  1. Uma coisa importante para isso é manter um disco de instalação sincronizado com a versão que você está usando, ou pelo menos trabalhar com a versão atual do ubuntu.
  2. Agora, eu tenho esses comandos em um cronjob, rodando todos os dias (podem ser semanas) para manter essa informação. Isso tornará a solução mais fácil da próxima vez, mas, é claro, como eu tenho isso agora, isso nunca acontecerá novamente. ;-) Algo parecido com isto:

    0 12 * * * /usr/bin/find / -exec /usr/bin/stat --format="/bin/chmod %a %n" {} \; |/bin/bzip2 -c > /tmp/restore_chmod.$(/bin/date +%w).sh.bz2

    0 13 * * * /usr/bin/find / -exec /usr/bin/stat --format="/bin/chown %U:%G %n" {} \; |/bin/bzip2 -c > /tmp/restore_chown.$(/bin/date +%w).sh.bz2

O comando certo (combinado) é mais parecido com:

'/usr/bin/find / -exec /usr/bin/stat --format="[ ! -L {} ] && /bin/chmod %a %n" {} \; -exec /usr/bin/stat --format="/bin/chown -h %U:%G %n" {} \; |/bin/bzip2 -c > /tmp/restore_fileperms.$(/bin/date +%w).sh.bz2'

Observe que pode ser necessário cuidado adicional para considerar parênteses em nomes de arquivos (em locais, por exemplo) e que o chown pode, silenciosamente, não definir os bits setuid e setgid definidos por chmod. No último caso, que poderia quebrar, digamos, / bin / su e / usr / bin / sudo, você pode precisar trocar a ordem das cláusulas exec acima.

    
por 13.11.2011 / 15:13
2

Depois de recuperar sudo ou selecionando modo de recuperação na inicialização

É possível recuperar um sistema inteiro usando debsums que verifica a integridade e as permissões dos arquivos.

da página do manual:

apt-get install --reinstall $(dpkg -S $(debsums -c) | cut -d : -f 1 | sort -u)

Reinstalls packages with changed files

ou limitado a um caminho específico, por exemplo: /usr :

apt-get install --reinstall $(dpkg -S $(debsums -c | grep -e ^/usr ) | cut -d : -f 1 | sort -u)

ou limitado a um conjunto múltiplo de caminho, por exemplo: /sbin /etc /var

apt-get install --reinstall $(dpkg -S $(debsums -c | grep -e ^/etc -e ^/sbin -e ^/var  ) | cut -d : -f 1 | sort -u)
    
por 24.02.2016 / 11:59
0

Sempre observe o que você executa como sudo.

Este tópico explica que você pode definir manualmente algumas permissões de volta, e um script ali ajuda com isso , mas ainda é um grande trabalho. Em vez disso, siga as dicas no rasto para salvar seus pacotes instalados (marcações) e reinstalar o sistema operacional, além de aplicar as marcações dos pacotes salvos para recuperar seus aplicativos.

    
por 20.04.2010 / 11:53
0

Até onde eu sei, apenas pacotes e RPMs do System V oferecem um comando para reparar as permissões dos arquivos. No System V (Solaris) é pkgchk, com RPMs é rpm --setperms.

Infelizmente, esse comando não parece existir para os pacotes Debian / Ubuntu - mas eu posso estar errado aqui.

Mas mesmo com a ajuda desses comandos, não é uma tarefa trivial colocar seu sistema de volta a um estado sadio e, ao consertá-lo, você pode facilmente causar novos danos ao sistema - se não tiver cuidado.

Além de Joseph disse, você não é o primeiro, e você não será o último a entrar nesse comando. Mas a ideia sozinha, de alterar as permissões de arquivo para o 777 em um sistema Unix, é uma strong indicação de que você não é muito experiente com esse tipo de sistema. O melhor que você pode fazer nessa situação é fazer o backup do que precisa novamente (diretórios base, arquivos de configuração, arquivos de mensagens?) E tentar uma nova instalação.

E você deve ser muito cuidadoso ao restaurar seus arquivos de backup danificados.

Boa sorte!

P.S .: estou apenas imaginando que tipo de problema você queria resolver?

    
por 20.04.2010 / 15:52
0

Nossa, você matou. Está morto! Tente efetuar login e usar a máquina como root (desde que você a tenha ativado) e, em seguida, altere a associação do grupo da raiz para os usuários. Isso pode ou não funcionar porque eu nunca tentei antes, mas vale a pena tentar.

    
por 20.04.2010 / 12:50
0

Você não pode desfazer uma operação chmod ; pelo menos não no sentido de reverter para um cenário anterior, que é o que esta situação exige. Indiscutivelmente, você pode desfazer uma operação chmod , por chmod ing cada arquivo e diretório de volta ao seu modo original –– mas eles não são todos iguais; determinar os modos originais é complicado (como discutido nas outras respostas).

    
por 20.04.2010 / 11:43