Come tornare sudo su Ubuntu?


12

Ho fatto questo:

sudo chown -R myname /usr/

e ora non posso usare il sudocomando a causa di questo errore:

sudo: deve essere setuid root

E mentre leggo questo significa che il proprietario di questo file /usr/bin/sudonon è il root. Ora è il mio utente a causa dell'abito nella /usrcartella.

Su molti forum e blog le persone suggeriscono di farlo come root:

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

... ma il problema è che devo accedere come root, ma non posso perché se scrivo sunel terminale la password è errata (in realtà uso la password che ho aggiunto al mio utente):

$ su
Password:
su: Authentication failure

Quindi posso riavere il sudocomando?

Modifica: Ubuntu è sotto Paralells sul mio Mac OS X.


Cosa intendi con "Uso la password che ho aggiunto al mio utente"? Quando lo usi su, ti verrà richiesta la password di root , non quella dell'utente come sudo. Conosci la password di root per questa macchina?
Caleb,

No, non ho mai avuto bisogno di aggiungerlo o modificarlo, esiste un valore predefinito?
Adam,

È necessario riavviare in modalità utente singolo. Quale distribuzione stai eseguendo?
Gilles 'SO- smetti di essere malvagio' il

1
Solo curioso, ma cosa ti ha fatto decidere di eseguire un sudo chmod -R cirk:cirk /usrCosa stavi cercando di realizzare?
Loosecannon,

1
Un programma che è stato installato da qualche parte in / usr / poiché non sapevo la posizione esatta del programma ho deciso di usare chown sull'intera cartella usr, e poiché sono un noob ho rovinato tutto di nuovo: P
Adam

Risposte:


5

Se si dispone di un sistema simile che è possibile utilizzare come guida per vedere qual è la proprietà corretta per tutti i file, è possibile avviare la modalità di ripristino, passare a una shell di root e ripristinare manualmente la proprietà corretta su tutti i file in /usr.

Il modo più rapido potrebbe essere reinstallare il sistema operativo o ripristinare dal backup.

In Ubuntu o simili, quindi non esiste una password di root per impostazione predefinita (l'account è disabilitato), motivo per cui non è possibile su.


8
Woah non ti preoccupare, questa non è la reinstallazione di Windows non è sempre il modo più semplice o veloce per fare qualsiasi cosa e certamente non insegna alle persone come risolvere i problemi. In questo caso, tutto ciò che deve fare è invertire l'azione intrapresa che può essere facilmente eseguita montando il file system in un altro ambiente come un LiveCD o la modalità di salvataggio suggerita (dipendente dalla distro).
Caleb,

@Caleb quando distruggi completamente i permessi su un grosso pezzo del filesystem che è. Non ha semplicemente rovinato sudo, presumibilmente ha dimenticato di menzionare nel suo post che ha usato -R (altrimenti avrebbe cambiato solo il proprietario della directory / usr stessa e non sudo). Ho anche descritto come invertire il processo, ma è un compito che richiede molto tempo e scrupoloso.
psusi

1
Questo è un caso di chownno chmod. Poiché tutto nella /usrcartella dovrebbe essere root:root, questa dovrebbe essere una soluzione semplice, non quella scrupolosa che chmodsignificherebbe un clobber.
Caleb,

2
@Caleb non tutto in / usr dovrebbe essere root: root.
psusi

6
@Caleb chownripristina i bit setxid. Ci sono alcuni file /usrche non sono di proprietà del root; più che fanno parte di un gruppo diverso (specialmente i programmi setgid in /usr/bin).
Gilles 'SO- smetti di essere malvagio' il

11

Dato che hai autorizzato le autorizzazioni sull'unica cosa che ti dà accesso a livello di root, avrai bisogno di aiuto dall'esterno dell'ambiente software corrente per risolvere questo problema.

Suggerisco che il modo più semplice è quello di avviare un LiveCD per la propria distribuzione, montare l'unità e modificare i permessi dei file usando i file chmodelencati da lì.

Potresti anche provare ad avviare in modalità utente singolo per ottenere una shell di root.

Tieni presente che di solito tutte le cose nella /usr/directory dovrebbero essere di proprietà, rootquindi dovresti essere in grado di fare un ricorsivo chownper riparare tutto ciò che hai rotto. ( Modifica: i commenti di Per @Gilles apparentemente eseguono chowninterruzioni setuid e setgid bit, quindi sarà necessario confrontare manualmente con un sistema esistente per ripristinare tutti quelli una volta risolto il problema.)

Tuttavia, dovrebbe essere molto FEW4111 . Quella in più è un'autorizzazione speciale ma che la rende eseguita come root anche quando eseguita come utente! Solo sudoe alcuni comandi selezionati dovrebbero avere questo bit di autorizzazione impostato. Se non hai eseguito a chmodper iniziare, probabilmente non è necessario risolverlo affatto , tutte le autorizzazioni dovrebbero già essere corrette. Non eseguire una grande chmodoperazione senza sapere quali dovrebbero essere tutte le autorizzazioni.


È possibile se il sistema operativo si trova in una macchina virtuale?
Adam,

Sì, questo non fa differenza. Puoi usare il runlevel 1 (qualcosa che puoi fare all'inizio del processo di avvio da grub / lilo o wahtever che è il tuo bootloader) oppure puoi configurare la VM per usare un'immagine ISO del LiveCD come dispositivo di avvio.
Caleb,

aham, ben prima di reinstallarlo, proverò il tuo consiglio :)
Adam,

ok penso di essere nel LiveCD, ora devo scrivere questo nel terminale? sudo chown -R root /usr/?
Adam,

Inizi con quello, ma non su /usrLivdCD, devi montarlo da qualche parte e correre contro quel percorso, diciamo /mnt/mydrive/usr. Quindi dovrai correggere il bit setuid /mnt/mydrive/usr/bin/sudo. Quindi guarda in / usr su livecd e vedi se ci sono altre proprietà oltre a root. find /usr -not -uid 0e cambia quelli per abbinarli. Quindi cerca cose con set di bit setuid o setgid diversi e assicurati che corrispondano anche quelli. Se hai un vero sistema Ubunutu da confrontare con quello sarebbe meglio.
Caleb,

4

Nella modalità di recupero di Ubuntu, inserisci i seguenti comandi ... Questo ha risolto il problema per me ..

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

Spero che questo risolva il tuo problema (o di qualcun altro)

Ho trovato questo qui in questo post del blog .


2

Questo è molto più semplice di quanto suggerito da altre risposte. Non è necessario formattare, riavviare o utilizzare CD live.

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

Questo è il modo più semplice per risolvere questo problema. Spiegazione, sudo è danneggiato (so che corrotto è il termine sbagliato, ma non funziona, quindi, dobbiamo evitare di usare sudo)

  • Usando il comando 1 (su root) , cambiamo l'utente in root senza usare sudo.
  • Usando il comando 2 (chown root: root / usr / bin / sudo && chmod 4755 / usr / bin / sudo) , fissiamo i permessi / la proprietà di sudo.
  • Usando il comando 3 (esci) , torniamo all'utente originale.

Ho testato questo metodo su Linux Mint. Che è un sistema simile a Ubuntu. Fammi sapere che questo metodo non funziona su nessun altro sistema operativo. Aggiornerà la risposta di conseguenza.

Grazie


a quanto ho capito, per impostazione predefinita l'account root non ha la password, quindi è impossibile fornire la password al primo passaggio su roote, poiché sudonon funziona, è impossibile impostare la password di root
TitanFighter,

1
Grazie mi ha aiutato.
Arun,

1

Questo è più semplice di quanto le persone lo stiano realizzando. Prova quanto segue:

  1. Invece di provare ad accedere come root usando il sucomando rotto , disconnettiti come utente corrente e accedi nuovamente come root tramite il tuo normale Display Manager (ad es. Schermata di accesso).
  2. Eseguire quanto segue sul terminale: chown root:root /usr/bin/sudo && chmod 4755 /usr/bin/sudo

Questo dovrebbe risolvere il sudocomando e farti funzionare di nuovo in pochissimo tempo.


0

Per accedere come root, senza su o sudo, puoi usare pkexec:

pkexec su

Ora modifica le autorizzazioni dei file:

chmod 440 /etc/sudoers
chmod 775 /etc/sudoers.d
chmod 440 /etc/sudoers.d/README
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.