Sudo vs root; eventuali differenze effettive?

44

Sto lavorando con un membro di supporto per un prodotto e insiste sul fatto che devo essere root per installare una serie di patch e che sudo non funzionerà; non fornisce una ragione, ma sembra fermamente convinto. Navigando su Superuser Non riesco a determinare alcun motivo possibile per questo, e in conferma, quando eseguo:

sudo -l

Ottengo:

...
User [MY USERNAME] may run the following commands on this host:
    (ALL) ALL

Ottenere l'accesso dal team Linux / server per essere effettivamente root non è un processo immediato come ho capito, quindi preferirei installarli da solo.

C'è qualche motivo pratico per cui sudo si comporterebbe diversamente rispetto a root per l'installazione di software su un server?

linux sudo root

— guardia forestale
fonte

2

Penso che dovresti rimetterlo su di lui. Come altri hanno dimostrato, ci sono una miriade di modi per ottenere radice usando sudo e se non può fornirti una ragione concreta sul perché sudo sia insufficiente, allora non ha una gamba su cui stare.

— Garrett,

1

Mi vengono in mente ambiente e sottocomandi. Penso che Hastur abbia fatto un buon lavoro con l'ambiente e Jayen abbia fatto un lavoro appiccicoso con sottocomandi, tubazioni e reindirizzamento.

— jww

2

Garrett ha un buon punto, ma prima di entrare in una potenziale gara di pipì, chiederei al membro dell'assistenza: l'hai provato in entrambi i modi e ha fallito in uno di questi modi? Potrebbe essere stato sulla strada del fallimento con sudoe gli script mentre gli script sono attualmente scritti. Se questo è il caso, allora la risposta sds' potrebbe essere più utile a voi: sudo su -.

— jww

34

Dipende fortemente da come si chiama il programma con sudoo su.
Ad esempio sul sistema in cui mi trovo in questo momento:

                  .bashrc                        
    COMMAND        $HOME   $USER  Env.  $PATH
 1. sudo -i        (root)   root  root  [1]
 2. sudo -s        (USER)   root  USER  /home/${USER}/bin:[1]
 3. sudo /bin/bash (USER)   root  USER  /home/${USER}/bin:[1]  
 4. sudo su        (root)   root  USER  [1]:/usr/games:/usr/local/games  
 5. sudo su -      (root)   root  root  [1]

Dove [1] = / usr / local / sbin: / usr / local / bin: / usr / sbin: / usr / bin: / sbin: / bin
Env = Le variabili di ambiente vengono ripristinate per 1 e 5, prese da $ USER in 2,3,4.

Quindi uno script o un programma che viene lanciato con una diversa opzione può vedere diverso $PATH, $HOME, il suo guscio in grado di leggere diversi .bashrc, .profilee le variabili d'ambiente. Legge il file relativo a $HOME. Ogni utente può modificare il proprio ambiente in modo diverso (variabili $PATH,, .bashrc, .profile, .bash_profile, alias ...). In particolare un utente può avere un diverso ordine delle directory nella sua $PATHe, di conseguenza, uno script può eseguire un comando, ad es. /home/$USER/binInvece di quello nel percorso previsto da root.

Puoi eseguire il programma sudo -icome se fossi loggato come root su -, ma puoi avere un comportamento diverso se lo esegui con sudo MyCommando con su -c MyCommand.

Da man su:

Nella parte descrittiva:
l'ambiente corrente viene passato alla nuova shell . Il valore di $ PATH viene reimpostato su / bin: / usr / bin per gli utenti normali o / sbin: / bin: / usr / sbin: / usr / bin per il superutente
...
Nella parte opzioni:
- , -l , --login
Fornisce un ambiente simile a quello che l'utente si aspetterebbe se l'utente avesse effettuato l' accesso direttamente .

Dall'uomo sudo

-i , --login
Esegue la shell specificata dalla voce del database delle password dell'utente di destinazione come shell di accesso. Ciò significa che i file di risorse specifici per l'accesso come .profile o .login verranno letti dalla shell. Se viene specificato un comando, viene passato alla shell per l'esecuzione tramite l'opzione -c della shell. Se non viene specificato alcun comando, viene eseguita una shell interattiva. sudotenta di passare alla home directory dell'utente prima di eseguire la shell. Il comando viene eseguito con un ambiente simile a quello che un utente riceverebbe al momento dell'accesso . La sezione Ambiente di comando nel manuale sudoers (5) documenta in che modo l'opzione -i influisce sull'ambiente in cui viene eseguito un comando quando viene utilizzata la politica sudoers.

— Hastur
fonte

Bella risposta. Sono ancora sudoalle prime armi con Linux, ma è un'altra differenza che ciò che puoi fare usando può essere limitato dalle autorizzazioni nel file sudoers rispetto a fare cose come root non ha queste limitazioni? L'ultima citazione in blocco forse implica che, ma se ho capito bene, sembra un'altra differenza sostanziale oltre il solo ambiente (o forse a causa dell'ambiente?).

— fixer1234

23

Se hai pieno sudoaccesso, puoi rootusarlo sudo su -, quindi il punto di sicurezza è controverso.

In effetti, c'è un modo per discernere la differenza tra un programma eseguito come roote un programma eseguito sotto sudo- usando getuidvs geteuid- ma questo è un trucco inventato. Perché un sistema di patch dovrebbe farlo?

— sds
fonte

5

A proposito su -, potrebbe voler usarlo in sudo -imodo da avere lo stesso ambiente di quando si accede direttamente.

— Cristian Ciupitu,

2

Se corri con es. sudo myscriptManterrai $ PATH e le variabili d'ambiente dalla shell in cui ti trovi. Se corri con sudo -i myscriptte corri come se effettuassi il login come root. Vedi la risposta con il nostro _zoo di chiamate :-) _

— Hastur

1

Penso che sia importante sottolineare che le variabili ambientali potrebbero non essere configurate allo stesso modo del sudologin come root

— secretformula,

1

@dmanexe: sudo non significa superutente do, è "switch user do". su e sudo possono essere usati per passare a qualsiasi utente piuttosto che solo al superutente. Inoltre non c'è nulla di pseudo su sudo, si ottiene davvero il root reale quando si esegue sudo non qualcosa di falso. Nota che la magia di sudo proviene davvero dal bit di autorizzazione setuid.

— Sdraiati Ryan il

2

sds, @CharlesDuffy: l'idea che sudo e su causino geteuid()ed getuid()essere diversi l'uno dall'altro è un mito. su e sudo cambiano gli ID utente reali ed effettivi con quelli dell'utente di destinazione prima di eseguire il comando o la shell specificati, tranne nella situazione molto insolita in cui li hai configurati esplicitamente per comportarsi diversamente. È possibile verificarlo (per sudo) eseguendo sudo id -ue sudo id -ru(entrambi mostrano 0), leggendo sudo (8) (in ESECUZIONE COMANDO ) o scrivendo un programma di test .

7

Ci sono alcune differenze se stai ottenendo una shell di root, come sottolineato da @Hastur.

Se non stai ottenendo una shell di root, allora ci sono più differenze. Il membro del supporto potrebbe avere esperienza nel provare a fare cose come sudo patch -p0 < /root/patch.filedove patchviene eseguito come root, ma <(piping da un file) non lo è.

— Jayen
fonte

1

A destra: il punto di vista pratico offre spesso suggerimenti che sono più difficili da individuare solo dalle pagine man. Per superare situazioni simili sei costretto a fare più ginnastica [:-)] ad esempio scrivere qualcosa di simile sudo /bin/bash -c "./patch -p0 < /root/patch". Ancora più delicato è il caso in cui si utilizza il reindirizzamento per creare un file >. Nel primo modo creerai un file che appartiene all'utente solo se hai il diritto di scrivere nella directory finale. In quest'ultimo modo creerai un file di proprietà di root ... il lato oscuro di Unix ;-)

— Hastur,

1

Credo che quando si utilizza l'accesso sudo, viene creato un file di registro, tuttavia quando si esegue direttamente tramite l'accesso root non esiste.

— Ashley Redman BSc
fonte

0

Dipende da quanto bene vuoi che sia l'accesso root. Se hai diversi utenti che eseguono compiti diversi su un sistema, sudo sarebbe più ideale. Un esempio che utilizzo di frequente è la necessità di riavviare un'applicazione o un database. La sicurezza è sempre meglio meno privilegiata. Uso i gruppi e consento solo a tali gruppi di eseguire azioni esplicite. Un buon libro che descrive questo processo è "Sudo Mastery: controllo dell'accesso degli utenti per persone reali". In realtà è un buon libro su sudo in generale ...

— meredithkm
fonte