Como posso reverter um chmod no diretório etc?


9

Eu acidentalmente executei o seguinte comando no diretório etc:

sudo chmod -R 700 /etc

Eu sei que fiz algo muito errado. Meu terminal agora imprime:

I have no name!@ubuntu: /$

Como posso reverter meu diretório etc para o seu estado anterior?

Tentei alterar as permissões, mas está falhando agora. Além disso, seria muito útil se alguém pudesse explicar o que realmente deu errado quando eu executei esse comando, etc. Foram apenas permissões de arquivo. Então, por que todo o sistema parece completamente explodido? Por que agora não há senhas de login funcionando? Eu sei que existe um arquivo no diretório etc que tem a ver com os usuários. Mas como a alteração de permissões prejudicou tudo? Alguns detalhes técnicos sobre isso seriam muito úteis.


3
Você precisa de uma listagem de diretório ( ls -laR) de outro sistema em execução. Qual versão é sua? Você pode alterar os diretórios para 755 e os arquivos e para 644, mas alguns devem ter modos diferentes (como / etc / shadow, por exemplo).
23-13

4
Ao digitar, sudovocê deve lê-lo na sua cabeça como "Estou concedendo a mim mesmo o poder supremo sobre o meu sistema, sem rede de segurança, tenho certeza de que sei o que estou fazendo? Estou certo de que digitei o que quis dizer?" antes de pressionar return.
msw

1
Com um sistema em funcionamento, você pode usar find /etc -type d ! -perm 755 -exec ls -ld {} \;e find etc -type f ! -perm -644 -exec ls -l {} \;encontrar diretórios e arquivos com modos não padrão. No Debian, são apenas 2 diretórios e 39 arquivos.
ott--

"Mas como a alteração de permissões prejudicou tudo?" - algumas coisas que precisavam ler esses arquivos agora não têm permissão para ler esses arquivos.
user253751

Respostas:


15

Uma coisa deu errado: o uso de sudocom esse comando. A -Ropção informa chmodpara definir recursivamente as permissões para esse diretório, o que é, em todos os casos, uma ação não recomendada (devemos chamá-lo de heresia) se você não souber o que está fazendo (quando isso aconteceu comigo, eu não emitiu o comando, mas uma GUI defeituosa o fez e meu sistema foi ligado).

Foram apenas permissões de arquivo. Então, por que todo o sistema parece completamente explodido?

O GNU / Linux é muito sensível às permissões de arquivos, pois foi construído com estabilidade e segurança em mente. O mesmo se aplica à maioria dos programas executados no GNU / Linux (ou seja, apache2descarta privilégios e usos de root www-data, ou usuário similar, e sua 700permissão não permite que ele leia / grave seus próprios arquivos).

Por que agora não há senhas de login funcionando?

Como você já mencionou, as senhas de login são armazenadas em um arquivo /etc/passwde somente o root (presumo que você não tenha alterado isso) pode lê-lo, mas o prompt de login (ou login da GUI) usa uma conta sem privilégios e, portanto, não pode ler o arquivo.

Mas como a alteração de permissões prejudicou tudo?

Mesmo como dito acima, o Linux é muito sensível às permissões de arquivo. Alguns programas até verificam as permissões de seus arquivos de configuração e, se não são esperados, não serão executados.

Como posso reverter meu diretório etc para o seu estado anterior?

Se você usa uma distribuição baseada em RPM, isso pode ser feito usando o rpm --setpermscomando, seria dolorosamente revertido um por um os pacotes, no sistema semelhante ao Debian apt-get --reinstall installé seu amigo. Outras soluções podem estar disponíveis, mas precisariam de um sistema funcional para isso.


5

Vamos ver, o que você fez é definir permissões em todo o diretório / etc, pois a leitura / gravação / execução é permitida apenas para o proprietário do arquivo / dir, negado para todos os outros. Se você estiver confuso com as permissões do arquivo, poderá ler mais em Wikipedia: Permissões tradicionais do UNIX .

O motivo pelo qual você explodiu seu sistema é porque muitos processos não podem mais ler suas configurações, não podendo acessar o / etc. Não será fácil recuperar o diretório / etc inteiro para o estado anterior. Como fazer isso dependerá da sua distribuição, mas basicamente significa reinstalar todos os pacotes que contêm qualquer arquivo dentro do / etc.

Como um rápido auxílio à banda para poder usar o sistema, a fim de corrigi-lo corretamente (reinstalando todos os pacotes com conteúdo em / etc, conforme indicado acima), você pode:

    # sudo find /etc -type d -exec chmod 775 '{}' \;
    # sudo find /etc -type f -exec chmod 664 '{}' \;

Com essas duas linhas, você definirá permissões liberais em todo o diretório / etc, com leitura / gravação permitida para o proprietário e o grupo e leitura permitida para todos os outros. A razão dos dois chmod é definir o bit de execução apenas nos diretórios. Alguns processos irão reclamar ou falhar, mesmo assim, incluindo qualquer executável em / etc, mas você poderá fazer a reinstalação descrita acima.

Esteja ciente de que, até que você recupere as permissões originais, seu sistema estará, no mínimo, em um estado inseguro.


2
Além disso, alguns programas não funcionam; O SSH, por exemplo, requer permissões restritivas em determinados arquivos. /etc/sudoersé outro.
Mel Boyce

1
Mas alguns arquivos /etcnão devem ser tornados legíveis pelo mundo! Restaure a partir de backups, é por isso que você os possui (ou é por isso que as pessoas pedem que você faça backups).
Tripleee

0

O 700 removeu o acesso a muitos arquivos para grupos e usuários do mundo (por exemplo, os arquivos agora têm rwx------permissões). Por exemplo, todos os usuários precisam ser capazes de ler /etc/passwd. Com sua configuração, somente o root pode ler agora /etc/passwd. Muitas coisas vão quebrar se você quebrar as permissões nos arquivos de /etc/maneiras imprevisíveis.

Você pode tentar reconstruir as permissões (supondo que você ainda possa mudar para o root) com base em um servidor ativo, mas isso é propenso a erros.

Sugiro restaurar a /etc/partir do backup se você tiver um (verifique se a restauração recupera as permissões ou, se sua solução de backup suportar, restaure apenas as permissões).

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.