Como recuperar o sudo no Ubuntu?

12

Eu fiz isso:

sudo chown -R myname /usr/

e agora não posso usar o sudocomando por causa desse erro:

sudo: deve ser raiz setuid

E enquanto eu leio isso significa que o proprietário deste arquivo /usr/bin/sudonão é a raiz. Agora é meu usuário por causa do chown na /usrpasta.

Em muitos fóruns e blogs, as pessoas sugerem fazer isso como root:

# chown root:root /usr/bin/sudo
# chmod 4111 /usr/bin/sudo

... mas o problema é que eu preciso fazer login como root, mas não posso, porque se eu escrever suno terminal a senha está errada (na verdade, eu uso a senha que adicionei ao meu usuário):

$ su
Password:
su: Authentication failure

Então, posso recuperar o sudocomando?

Edit: Meu Ubuntu está sob Paralells no meu Mac OS X.

— Adão
fonte

O que você quer dizer com "Eu uso a senha que adicionei ao meu usuário"? Quando você usa su, você será solicitado a senha de root , e não a senha do usuário como com sudo. Você conhece a senha root desta máquina?

— Caleb

Não, nunca precisei adicioná-lo ou modificá-lo. Existe um padrão para ele?

— Adam

Você precisa reiniciar no modo de usuário único. Qual distribuição você está executando?

— Gilles 'SO- stop being evil'

1

Apenas curioso, mas o que fez você decidir executar o sudo chmod -R cirk:cirk /usrque você estava tentando realizar?

— 21711 loosecannon

1

Um programa que foi instalado em algum lugar em / usr /, como eu não sabia a localização exata do programa, decidi usar chown em toda a pasta usr e, como sou noob, estraguei tudo de novo: P

— Adam

5

Se você possui um sistema semelhante que pode ser usado como um guia para ver qual é a propriedade correta de todos os arquivos, é possível inicializar no modo de recuperação, ir para um shell raiz e restaurar manualmente a propriedade correta para todos os arquivos. arquivos em /usr.

A maneira mais rápida pode ser reinstalar o SO ou restaurar a partir do backup.

No Ubuntu ou similar, então não há senha de root por padrão (a conta está desabilitada), e é por isso que você não pode su.

— psusi
fonte

8

Woah, vá com calma lá, isso não é a reinstalação do Windows nem sempre é a maneira mais fácil ou rápida de fazer qualquer coisa e certamente não ensina as pessoas a resolver problemas. Nesse caso, tudo o que ele precisa fazer é reverter a ação que ele executou, o que pode ser feito facilmente montando o sistema de arquivos em outro ambiente, como um LiveCD ou o modo de recuperação que você sugeriu (dependente da distribuição).

— Caleb

@ Caleb quando você lixeira completamente as permissões em uma grande parte do sistema de arquivos é. Ele não estragou o sudo, presumivelmente ele esqueceu de mencionar em seu post que usava -R (caso contrário, isso só mudaria o proprietário do diretório / usr e não o sudo). Também descrevi como reverter o processo, mas é uma tarefa muito demorada e meticulosa.

— Psusi 19/07/11

1

Este é um caso de chownnão chmod. Como tudo na /usrpasta deve ser root:root, essa deve ser uma solução fácil, não a correção minuciosa que um chmodclobber significaria.

— Caleb

2

@ Caleb nem tudo em / usr deve ser root: root.

— psusi 19/07/11

6

@Caleb chownredefine os bits setxid. Existem alguns arquivos /usrque não pertencem à raiz; mais que estão em um grupo diferente (especialmente nos programas setgid /usr/bin).

— Gilles 'SO- stop being evil'

11

Como você concedeu as permissões à única coisa que lhe dá acesso no nível raiz, precisará de ajuda de FORA do ambiente de software atual para corrigir isso.

Sugiro que a maneira mais fácil é inicializar um LiveCD para sua distribuição, montar sua unidade e alterar as permissões de arquivo usando as chmodlistadas a partir daí.

Você também pode tentar inicializar no modo de usuário único para obter um shell raiz.

Esteja ciente de que geralmente todas as coisas no /usr/diretório devem ser de propriedade; rootportanto, você deve ser capaz de executar uma recursiva chownpara corrigir o que quebrou. ( Edit: Por @Gilles comenta aparentemente correndo chownbreaks setuid e setgid pedaços, para que você vai precisar para comparar manualmente para um sistema existente para restaurar todos os uma vez que você corrigir a propriedade novamente.)

No entanto, muito poucos devem ser 4111. Essa extra é uma permissão especial, mas que a executa como root, mesmo quando executada como usuário! Somente sudoe alguns comandos selecionados devem ter esse bit de permissão definido. Se você não executou um chmodpara começar, provavelmente não precisa corrigir isso , todas as permissões já devem estar corretas. Não execute uma grande chmodoperação sem saber quais devem ser todas as permissões.

— Caleb
fonte

É possível se o sistema operacional estiver em uma máquina virtual?

— 19411 Adam

Sim, isso não faz diferença. Você pode usar o nível de execução 1 (algo que você pode fazer no início do processo de inicialização do grub / lilo ou qualquer que seja o seu carregador de inicialização) ou pode configurar a VM para usar uma imagem ISO do LiveCD como dispositivo de inicialização.

— Caleb

aham, bem antes de eu reinstalá-lo, vou tentar o seu conselho :)

— Adam

ok acho que estou no LiveCD, agora preciso escrever isso no terminal? sudo chown -R root /usr/?

— 19411 Adam

Você começa com isso, mas não no /usrLivdCD, você precisa montá-lo em algum lugar e correr nesse caminho, digamos /mnt/mydrive/usr. Então você precisará corrigir o bit setuid /mnt/mydrive/usr/bin/sudo. Então olhe através do / usr no livecd e veja se há outras propriedades além do root. find /usr -not -uid 0e mude para combinar. Em seguida, procure por itens com diferentes bits setuid ou setgid e verifique se eles também correspondem. Se você tem um sistema Ubunutu real para comparar, seria melhor.

— Caleb

4

No modo de recuperação do Ubuntu, digite os seguintes comandos ... Isso corrigiu o problema para mim ..

mount -o remount,rw /
mount --all
chown root:root /usr/bin/sudo
chmod 4755 /usr/bin/sudo
restart

Espero que isso resolva seu problema. (Ou de outra pessoa)

Encontrei este aqui neste post do blog .

— Usuário do Ubuntu
fonte

2

Isso é muito mais fácil do que o sugerido por outras respostas. Não há necessidade de formatar, reiniciar ou usar o live CD.

su root # then enter your password to switch to root user
chown root:root /usr/bin/sudo && chmod 4755 /usr/bin/sudo
exit # to get back to the original user

Essa é a maneira mais fácil de corrigir esse problema. Explicação, sudo está corrompido (eu sei que corrompido é o termo errado, mas não está funcionando, portanto, precisamos evitar o uso de sudo)

Usando o comando 1 (su root) , alteramos o usuário para root sem usar o sudo.
Usando o comando 2 (raiz do chown: root / usr / bin / sudo && chmod 4755 / usr / bin / sudo) , corrigimos as permissões / propriedade do sudo.
Usando o comando 3 (exit) , voltamos ao usuário original.

Eu testei esse método no Linux mint. Que é um sistema semelhante ao ubuntu. Deixe-me saber que este método não funciona em nenhum outro sistema operacional. Atualizará a resposta de acordo.

obrigado

— divyenduz
fonte

como eu entendo, por padrão conta root não tem senha, por isso é impossível para fornecer a senha na primeira etapa su root, e porque sudonão trabalho, é impossível senha definida raiz

— TitanFighter

1

Obrigado, isso me ajudou.

— Arun

1

Isso é mais simples do que as pessoas estão fazendo. Tente o seguinte:

Em vez de tentar suefetuar login como root usando o comando quebrado , efetue logon como seu usuário atual e faça login novamente como root através do seu Gerenciador de exibição normal (por exemplo, tela de login).
Execute o seguinte no terminal: chown root:root /usr/bin/sudo && chmod 4755 /usr/bin/sudo

Isso deve corrigir o sudocomando e colocá-lo em funcionamento novamente em pouco tempo.

— user7089
fonte

0

Para fazer login como root, sem su ou sudo, você pode usar o pkexec:

pkexec su

Agora altere as permissões dos arquivos:

chmod 440 /etc/sudoers
chmod 775 /etc/sudoers.d
chmod 440 /etc/sudoers.d/README

— Jagmeet Singh Bains
fonte