Eu cometi um erro terrível, tentei consertar sozinho, mas preciso de ajuda.
Devido a um erro de sintaxe, todas as permissões de arquivos e pastas estavam sendo alteradas: felizmente eu vi isso enquanto estava acontecendo e parei com sucesso. "Apenas" /bin , /boot e /dev são afetados. Aqui está um trecho do que aconteceu (log completo: link ):
Apr 11 21:34:08 *** sftp-server[20582]: set "/.newrelic" mode 40754
Apr 11 21:34:08 *** sftp-server[20582]: set "/bin" mode 40554
Apr 11 21:34:09 *** sftp-server[20582]: set "/boot" mode 40554
Apr 11 21:34:09 *** sftp-server[20582]: set "/cgroup" mode 40754
Apr 11 21:34:09 *** sftp-server[20582]: set "/dev" mode 40754
Apr 11 21:34:09 *** sftp-server[20582]: opendir "/.newrelic"
Apr 11 21:34:09 *** sftp-server[20582]: closedir "/.newrelic"
Apr 11 21:34:09 *** sftp-server[20582]: opendir "/.newrelic"
Apr 11 21:34:10 *** sftp-server[20582]: closedir "/.newrelic"
Apr 11 21:34:10 *** sftp-server[20582]: opendir "/"
Apr 11 21:34:10 *** sftp-server[20582]: closedir "/"
Apr 11 21:34:10 *** sftp-server[20582]: opendir "/bin"
Apr 11 21:34:10 *** sftp-server[20582]: closedir "/bin"
Apr 11 21:34:10 *** sftp-server[20582]: set "/bin/mknod" mode 100754
Apr 11 21:34:10 *** sftp-server[20582]: set "/bin/cat" mode 100754
Apr 11 21:34:10 *** sftp-server[20582]: set "/bin/ping6" mode 100754
Por exemplo, o MySQL não está mais rodando, e temo que mais danos tenham sido causados.
Eu tentei restaurar permissões de leitura e execução nessas pastas e arquivos, mas na verdade não sei em que estado eles estavam anteriormente.
Como posso reverter meu sistema para um estado de funcionamento?
Na verdade, parece que o sistema foi mais afetado que o log estava dizendo!
talvez por causa da pasta dev, talvez symlinks ... não sei, mas depois de rastrear fóruns etc e tentar pasta por pasta, finalmente salvei o servidor com
for package in $(rpm -qa); do rpm --setperms $package; done
Um thx especial para @Gilles e sua excelente resposta
Um especial NO Thx! @dhag por editar minha pergunta até remover minha fórmula de cortesia
Você deve ser capaz de restaurar permissões de um shell de root, se você conseguir iniciar um. Você deve ser capaz de obter um shell de root efetuando login como root no console. Neste ponto, dependendo da sua configuração, você pode ou não ser capaz de obter acesso root de uma conta comum com su ou sudo , e você provavelmente não conseguirá fazer login em nenhuma conta não-root .
Se a transcrição que você postou estiver completa, você teve a sorte de não ser afetados os arquivos cujas permissões são mais difíceis de restaurar ( /etc e /var ).
Apr 11 21:34:08 *** sftp-server[20582]: set "/.newrelic" mode 40754 Apr 11 21:34:08 *** sftp-server[20582]: set "/bin" mode 40554 Apr 11 21:34:09 *** sftp-server[20582]: set "/boot" mode 40554 Apr 11 21:34:09 *** sftp-server[20582]: set "/cgroup" mode 40754 Apr 11 21:34:09 *** sftp-server[20582]: set "/dev" mode 40754
40754 (notação octal) significa um diretório, gravável pelo proprietário, executável pelo proprietário e grupo, e legível por todos. Somente os três dígitos mais à direita indicam as permissões, os dígitos anteriores codificam o tipo de arquivo e não podem ser alterados. Como a permissão “executar” em um diretório, na verdade, significa a permissão para acessar arquivos nesse diretório, os arquivos nesses diretórios não podem mais ser acessados pela maioria dos usuários. A maioria dos diretórios de nível superior deve ter a permissão 755, o que significa legível e executável por todos e gravável apenas pelo proprietário (as exceções são /lost+found , que normalmente é 700, /tmp , que deve ser 1777 e sistemas de arquivos especiais como /proc ou /sys pode não ser gravável pelo seu proprietário). Eu não sei o que é /.newrelic , não é um diretório padrão de nível superior.
chmod 755 /bin /boot /cgroup /dev
Apr 11 21:34:10 *** sftp-server[20582]: set "/bin/mknod" mode 100754 …
A maioria dos arquivos em /bin e /sbin deve ser legível e executável por todos, e gravável apenas pelo seu proprietário. Alguns deles precisam ser setuid .
chmod a+x /bin/* /sbin/*
chmod 4755 /bin/su /bin/sudo /bin/mount /bin/umount /bin/ping /bin/ping6
chmod 4754 /bin/fusermount
Em /boot , acho que todos os arquivos e diretórios devem ser legíveis e os diretórios devem ser executáveis, mas os arquivos não devem.
find /boot -type d -exec chmod 755 {} + -type f -exec chmod 644 {} +
Isso deixa /dev , onde as permissões variam muito de arquivo para arquivo. Felizmente, /dev é um sistema de arquivos na memória, portanto, o conteúdo ficará bem após a reinicialização. Se você puder e quiser restaurar as permissões em /dev sem reinicializar, acho que o seguinte comando fará isso:
udevadm trigger --sysname-match='*'
Tags boot permissions chmod