Alguma recuperação disso? sudo chmod 600. *

Question

AVISO - NÃO EXECUTE EXECUTE O COMANDO MENCIONADO

Então parece que eu fiz algo muito burro aqui para dizer o mínimo. Eu estava tentando alterar as permissões para alguns arquivos em um diretório que tudo começou com . para ler / escrever somente para sudo / root.

Minha tentativa de alterar vários arquivos de uma vez parece ter feito algo terrivelmente global. Enquanto dentro de um diretório (não estava no diretório raiz) eu corri sudo chmod 600 .* e bem, eu estou postando isso do meu telefone agora ... Eu ainda tenho a janela do terminal aberta no momento, mas eu tenho certeza se o laptop vai dormir eu estou completamente feito. Hilariamente isso significa que há uma ligeira urgência para essa questão.

Ah, e isso parece ter mudado as permissões em todos os lugares que eu estou supondo. Nem consigo executar os comandos ls ou cd .. . Uma tentativa de cd /home/brian ou cd ~ fornece o erro bash: cd: /home/brian: Permission Denied e qualquer tentativa de um comando sudo diz apenas bash: /usr/bin/sudo: Permission Denied

Eu tenho medo de reiniciar, nenhuma pista se existe alguma recuperação interna de algo tão idiota, mas imaginei que tentaria perguntar aqui antes de piorar as coisas. Eu sou um Linux muito novo como o meu principal convertidor de SO e venho defendendo um pouco ultimamente, mas ai, esse aqui é um pouco difícil. Qualquer pensamento de coisas para tentar seria imensamente apreciado.

EDIT: Eu queria fornecer esclarecimentos sobre como / onde este comando foi executado. Isso foi executado a partir de /.atx $ , apenas um diretório arbitrário, mas mais detalhes abaixo.

Enquanto logado como meu nome de usuário normal brian , eu tinha um terminal aberto para /.atx que continha três arquivos de texto de tipo de configuração. Cada nome de arquivo foi iniciado com . . Esse diretório / nome / os arquivos não fazem parte de um pacote comum, apenas um conjunto arbitrário de configurações que eu estava programaticamente circulando. Os arquivos continham algumas informações de string de conexão do servidor SQL e queriam que eles ficassem semi-obscurecidos.

    

Answer 1

Whew, a recuperação aqui foi realmente mais suave do que eu esperava e tudo parece em boa forma novamente.

Muito obrigado ao @CharlesGreen por uma explicação de como esse comando estendeu um diretório. Também obrigado ao @Panther por informações sobre como entrar no modo de recuperação para um problema um pouco relacionado. (se vocês querem compartilhar novamente seus comentários como respostas, eu os defenderei)

Felizmente, ao contrário do post vinculado, isso parece ter uma correção muito direta. Parece que quando eu executei o comando sudo chmod 600 .* de apenas um diretório em / ele expandiu a .* porção UP para o diretório raiz verdadeiro alterando as permissões de . de / fazendo com que todas as outras permissões caíssem. / p>

A "correção" para isso foi inicializar no modo de recuperação, montar novamente a unidade como leitura / gravação, indo para a raiz principal ( cd / ) e, em seguida, chmod +rx . . Depois de uma reinicialização, tudo parece estar de volta ao normal.

Moral da história, a execução de um comando em .* pode, pelo menos, impactar, algumas vezes, o diretório ABAVE the current. Eu pretendia impactar apenas arquivos que começaram com . ... oops.

Muito obrigado a todos que comentaram e ajudaram.

    

Answer 2

  

A "correção" para isso foi inicializar no modo de recuperação, montar novamente a unidade como leitura / gravação, indo para a raiz principal (cd /) e, em seguida, chmod + rx .. Após uma reinicialização, tudo parece volte ao normal.

Só para deixar claro para futuros leitores que podem se deparar com isso como a resposta aceita, há preocupações com a solução chmod +x como uma solução geral. Essa questão específica parece ter sido o diretório inicial dos usuários, portanto algumas das preocupações abaixo podem ser baixas, mas se isso foi aplicado a um servidor de negócios e impactou vários usuários ou outros diretórios de dados, a solução não é sugerida.

No lado positivo , essa etapa permitiria que o usuário recuperasse o acesso aos arquivos para que eles pudessem ser copiados para um meio de backup para evitar mais perdas. E, no final do dia, esse é o principal objetivo durante qualquer esforço de recuperação de dados.

A maior preocupação é que os arquivos originais possam ter permissões específicas aplicadas que estão faltando agora. Alguns programas - especificamente ssh - aplicam permissões de arquivo para garantir ainda mais sua segurança e não funcionarão se a permissão +rw estiver definida em sua pasta e arquivos.

Outra preocupação é que, se isso for aplicado na pasta raiz ( / ) de forma recursiva, haverá outros arquivos que podem estar abertos para qualquer pessoa no sistema visualizar e modificar. Em um cenário de negócios em que o servidor pode conter dados confidenciais (PCI / financeira ou de saúde / informações do HIPAA), esse acesso pode levar a descobertas e repercussões de auditoria.

Em um ambiente pessoal / doméstico, essa recuperação é provavelmente perfeitamente aceitável. Apenas observe que algumas coisas podem estar silenciosamente quebradas ou agir de maneira estranha.

Em um ambiente de negócios, o uso dessa recuperação para recuperar o acesso aos dados pode ser usado, mas, no final, qualquer alteração importante como essa deve ser resolvida com a reinstalação do servidor e a recuperação de um backup.

( Você tem um backup atual, não é?; -) )