Sudo vs radice; differenze effettive?

Dipende fortemente da come chiami il tuo programma con sudo o su .
Per esempio. sul sistema su 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
Le variabili Env=Environment vengono reimpostate per 1 e 5, prese da $USER in 2,3,4.

Quindi uno script o un programma avviato con un'opzione diversa può vedere $PATH diversi , $HOME , la sua shell può leggere diversi .bashrc ,.profile e variabili d'ambiente. Legge il file relativo al $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 nel suo $PATH e, di conseguenza, uno script può eseguire un comando, ad es. in /home/$USER/bin invece poi quello nel percorso previsto da root.

Puoi eseguire il programma in sudo -i dato che eri loggato come root con su - , ma puoi avere un comportamento diverso se lo esegui con sudo MyCommand o con su -c MyCommand .

Da man su :

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

Dall'uomo sudo

-i , --Accedere
Eseguire la shell specificata dalla voce del database delle password dell'utente di destinazione come shell di login. 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. sudo tenta di passare alla home directory di quell'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 Command Environment nel manuale sudoers(5) documenta come l'opzione -i influisce sull'ambiente in cui viene eseguito un comando quando la politica sudoers è in uso.

Se hai sudo completo accesso, puoi diventare root utilizzando sudo su - , quindi il punto di sicurezza è discutibile.

In effetti, c'è un modo per discernere la differenza tra un programma eseguito come root e un programma è stato eseguito con sudo - utilizzando getuid rispetto a geteuid - ma questo è un trucco artificioso. Perché un sistema di patch dovrebbe farlo?

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

Se non ottieni una shell di root, allora ci sono più differenze. Il membro dell'assistenza potrebbe avere esperienza nel provare a fare cose come sudo patch -p0 < /root/patch.file dove patch viene eseguito come root, ma < (piping da un file) non lo è.