É 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:
- 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.
-
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.