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

Eu digitei recentemente 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 de redefinir as permissões da pasta para seu estado original?

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

Corri novamente o mesmo tipo de problema (algum bug em um script que estava escrevendo) e o resolvi, mas você precisa pedir a ajuda de algum especialista. Seja muito cauteloso!

Primeiro, minha situação foi mais fácil de resolver porque eu tinha um sistema de inicialização dupla (Ubuntu e minha antiga instalação do Fedora), mas executar o sistema operacional a partir de um CD / DVD ou uma chave USB deve 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

Em seguida, 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 mais complicado (de fato, no meu caso, instalei um sistema Ubuntu no Virtual Box no fedora e obteve 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.

Consegui novamente iniciar no Ubuntu.

O conteúdo do 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
(...)

Não testei, mas deve funcionar também 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
(...)

Obviamente, você deve tomar cuidado aqui, que o UID e o GID são iguais nos dois sistemas, mas para os usuários e grupos relacionados ao sistema, isso não deve ser um problema.

Editar:

Além disso, o proprietário da configuração anulará os sinalizadores 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 somente deve definir permissões DEPOIS proprietários da configuração. SALVAR informações completas de permissão de arquivo junto com 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, executando todos os dias (pode demorar semanas) para manter essas informações. Facilitará a solução da próxima vez, mas, é claro, como eu tenho isso agora, isso nunca mais acontecerá. ;-) Algo assim:

   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 cuidados adicionais podem ser necessários para contabilizar parênteses nos nomes de arquivos (em locais, por exemplo) e que o chown pode silenciosamente desabilitar os bits setuid e setgid definidos pelo chmod. No último caso, que quebraria, por exemplo, / bin / su e / usr / bin / sudo, talvez você precise trocar a ordem das cláusulas exec acima.

Após recuperar o sudo ou selecionar o modo de recuperação na inicialização

É possível recuperar um sistema inteiro usando debsums que verificam a integridade e as permissões do arquivo.

na página do manual:

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

Reinstala pacotes com arquivos alterados

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)

Sempre observe o que você executa como sudo.

Este tópico explica que você pode definir manualmente algumas permissões novamente, e um script ajuda nisso, mas ainda é um grande trabalho. Em vez disso, siga as dicas na etapa para salvar seus pacotes instalados (marcações) e reinstalar o sistema operacional, e aplique suas marcações de pacotes salvos para recuperar seus aplicativos.

Tanto quanto eu sei, apenas pacotes do System V e RPMs oferecem um comando para reparar permissões de arquivo. No Sistema V (Solaris), é pkgchk, com RPMs, é rpm --setperms.

Infelizmente, nenhum comando parece existir para pacotes Debian / Ubuntu - mas posso estar errado aqui.

Mas mesmo com a ajuda desses comandos, não é uma tarefa trivial trazer o sistema de volta ao estado normal e, ao repará-lo, você pode facilmente causar novos danos ao seu sistema - se você não for cuidadoso.

Além de Joseph ter dito, você não é o primeiro e não será o último a entrar nesse comando. Mas a idéia sozinha, alterar as permissões de arquivo para 777 em um sistema Unix, é uma forte indicação de que você não tem muita experiência com esse tipo de sistema. O melhor que você pode fazer nessa situação é fazer backup do que você precisará novamente (diretórios pessoais, arquivos de configuração, arquivos de mensagens?) E tentar uma nova instalação.

E você deve ter muito, muito cuidado ao restaurar seus arquivos de backup danificados.

Boa sorte!

PS: Só estou me perguntando que tipo de problema você queria resolver?

Uau, você matou. Está morto! Tente fazer login e usar a máquina como raiz (desde que você a ativou) e altere a associação ao grupo de raiz para usuários. Isso pode ou não funcionar, porque eu nunca tentei antes, mas vale a pena tentar.

Você não pode desfazer uma chmodoperação; pelo menos não no sentido de reverter para uma configuração anterior, que é o que essa situação exige. Indiscutivelmente, você pode desfazer uma chmodoperação, chmodcolocando 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).