Não é possível acessar a Internet depois de executar o sudo chown -R $ USER $ USER / usr / lib /

4

Eu queria atualizar o PyCharm e, ao executar o Pycharm, não era possível, pois dizia que eu não tinha permissões suficientes. Então eu corro o seguinte comando:

$ sudo chown -R $USER$USER /usr/lib/

Consegui atualizar o PyCharm com sucesso, mas agora minha conexão com a Internet não está funcionando e, na verdade, não consegui executar o sudo depois de acessar o modo de recuperação após este tutorial .

Eu realmente preciso que minha conexão com a Internet funcione novamente, então, por favor, agradeço sua ajuda para resolver esse problema.

Eu tenho que mencionar que estou usando uma inicialização dupla.

    
por lmiguelvargasf 21.12.2016 / 23:43

2 respostas

9

Qualquer tipo de operação chown nos diretórios do sistema é muito perigoso .

A maneira mais fácil de resolver esse problema seria apenas reinstalar completamente o sistema operacional.

Se você tiver sorte (e for um pouco arriscado), poderá recuperar simplesmente executando o comando abaixo no modo de recuperação:

chown -R root:root /usr/lib

Embora os arquivos mais sejam de propriedade de root em /usr/lib , ainda pode haver um arquivo ocasional que não é que causará grandes problemas se não for de propriedade ativa pelo usuário apropriado. Na verdade, em sua instalação Linux (média), a maioria dos arquivos nesse diretório é de propriedade de root / root , então isso definitivamente vale a pena se a reinstalação não for desejada.

Caso contrário, você teria que passar por cada arquivo e atribuir manualmente novamente as permissões aos seus valores normais (normalmente, o significado pertence a root , mas não em todos os casos). Ocasionalmente, você pode reinstalar todos os pacotes (usando apt --reinstall install <packagename> ), mas isso não é garantido, e ainda pode causar mais dores de cabeça do que soluciona. Realmente, você estaria passando por cada arquivo e executando dpkg -L neles.

Quanto a preservar seus arquivos em seu sistema atual (se você descer a reinstalação do caminho do sistema operacional), você pode usar uma unidade flash no modo de recuperação. Se você precisar fazer upload de alguns arquivos para o Git no último segundo, você provavelmente poderá usar um Live DVD (obtendo chaves SSH e qualquer coisa importante da sua instalação destruída).

No futuro, para evitar que esse tipo exato de problema ocorra novamente, verifique se você tem um backup (funcionando - verifique!) do sistema e de todos os arquivos importantes.

Além disso, é importante observar que sudo é não uma solução de correção única para qualquer erro de permissão e não deve ser usado dessa maneira ! Se houver um erro de permissão, provavelmente há uma boa razão para você não ter permissão para fazer isso, então investigue e resolva de uma maneira sã.

    
por Kaz Wolfe 21.12.2016 / 23:49
14

Na verdade, não é necessário reinstalar. Esta situação é bastante reparável. Acabei de executar o mesmo comando no meu sistema e corrigi-lo em cerca de 10 minutos.

Você precisará inicializar no modo de recuperação ou usar um USB / DVD ao vivo de qualquer versão do Linux (preferencialmente o Ubuntu!)

Se você preferir a recuperação, consulte Como inicializo a recuperação modo?

Eu usei um USB ao vivo com o Xubuntu 16.04 que eu tinha que entregar. Se estiver usando uma sessão ao vivo, após a inicialização, abra um terminal e identifique sua partição raiz (principal), usando comandos como lsblk e sudo fdisk -l . Quando você souber qual delas é (provavelmente será uma partição ext4 ), monte-a. Aqui eu estou chamando a partição raiz /dev/sda1 - você precisa substituir isso com o rótulo real.

sudo mount /dev/sda1 /mnt

agora verifique se é a partição certa fazendo ls /mnt - você deve ver usr sys proc dev home root e outras coisas que você esperaria encontrar no topo da árvore do sistema de arquivos. OK, vamos corrigir a propriedade (em todos esses comandos, por favor, anote cuidadosamente o : e certifique-se de colocá-los nos lugares certos).

sudo chown -R root: /mnt/usr/lib

Isso quase corrige isso. No meu sistema, antes de quebrá-lo, verifiquei todas as propriedades no local

$ find /usr/lib -not -user root

não retorna nada - o root possui tudo, mas

$ find /usr/lib -not -group root -ls

Aumentei isto:

-rwxr-sr-x   1 root     mail          /usr/lib/emacs/24.5/x86_64-linux-gnu/movemail
-rwxr-sr-x   1 root     tty           /usr/lib/mc/cons.saver
-rwsr-xr--   1 root     messagebus    /usr/lib/dbus-1.0/dbus-daemon-launch-helper
-rwxr-sr-x   1 root     utmp          /usr/lib/x86_64-linux-gnu/utempter/utempter

Seu sistema não será exatamente o mesmo, mas você deve chown desses arquivos, se você os tiver, e procurar equivalentes se não (por exemplo, se o sistema for de 32 bits, você terá x86 em vez de %código%). Eu consertei isso com:

sudo chown :mail /mnt/usr/lib/emacs/24.5/x86_64-linux-gnu/movemail
sudo chown :tty /mnt/usr/lib/mc/cons.saver
sudo chown :messagebus /mnt/usr/lib/dbus-1.0/dbus-daemon-launch-helper
sudo chown :utmp /mnt/usr/lib/x86_64-linux-gnu/utempter/utempter

(se estiver usando o modo de recuperação, você não precisará do x86_64 no início desses caminhos)

Como apontado por @grawity, você também precisa reparar o /mnt bit em setuid que é limpo por dbus-daemon-launch-helper :

sudo chmod u+s /mnt/usr/lib/dbus-1.0/dbus-daemon-launch-helper
    
por Zanna 22.12.2016 / 00:34