Perché le variabili PATH sono diverse quando si esegue tramite sudo e su?

Sulla mia macchina virtuale fedora, quando sono in esecuzione con il mio account utente ho /usr/local/binnel mio percorso:

[justin@justin-fedora12 ~]$ env | grep PATH
 PATH=/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/justin/bin

E allo stesso modo quando si esegue su:

[justin@justin-fedora12 ~]$ su -
Password: 
[root@justin-fedora12 justin]# env | grep PATH
PATH=/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/justin/bin

Tuttavia, quando si esegue tramite sudo, questa directory non si trova nel percorso:

[root@justin-fedora12 justin]# exit
[justin@justin-fedora12 ~]$ sudo bash
[root@justin-fedora12 ~]# env | grep PATH
PATH=/usr/kerberos/sbin:/usr/kerberos/bin:/sbin:/bin:/usr/sbin:/usr/bin

Perché il percorso dovrebbe essere diverso quando si esegue tramite sudo?

Dai un'occhiata /etc/sudoers. Il file predefinito in Fedora (così come in RHEL, e anche Ubuntu e simili) include questa riga:

Defaults    secure_path = /sbin:/bin:/usr/sbin:/usr/bin

Ciò garantisce che il percorso sia pulito quando si eseguono file binari su sudo. Questo aiuta a proteggere da alcune delle preoccupazioni rilevate in questa domanda . È anche conveniente se non hai /sbine /usr/sbinnel tuo percorso.

Il comando su -eseguirà il profilo degli utenti root e assumerà l'ambiente dell'utente incluso il percorso ecc sudo.

Se vuoi sudocomportarti come su -allora, usa l'opzione sudo -i [commandche eseguirà il profilo dell'utente

Se ti piacerebbe su -comportarti come sudonon usare il trattino, basta usaresu [command]

Puoi controllare perché (è diverso) eseguendo sudo sudo -V.

Ad esempio, su Linux, eseguire:

$ sudo sudo -V | grep PATH
Value to override user's $PATH with: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

^{Nota: su MacOS / BSD, basta eseguire: sudo sudo -V.}

L'elenco sopra è limitato a causa del plug-in della politica di sicurezza predefinito in alcune distribuzioni Linux.

Questo è ulteriormente spiegato in man sudoers:

Se l' secure_pathopzione è impostata, il suo valore verrà utilizzato per la PATHvariabile di ambiente.

secure_path- Percorso utilizzato per ogni comando eseguito da sudo. Se non ti fidi che le persone che eseguono sudo dispongano di una PATHvariabile d'ambiente sana , potresti voler usare questo.

Un altro uso è se si desidera che il "percorso radice" sia separato dal "percorso utente". Gli utenti nel gruppo specificato exempt_groupdall'opzione non sono interessati da secure_path. Questa opzione non è impostata per impostazione predefinita.

In tal caso, puoi cambiarlo eseguendo sudo visudoe modificando il file di configurazione e modificando il tuo secure_path(aggiungendo un percorso aggiuntivo separato da :) o aggiungendo il tuo utente exempt_group( in modo da non essere influenzato dalle secure_pathopzioni).

O per passare PATHtemporaneamente l'utente , è possibile eseguire:

sudo env PATH="$PATH" my_command

e puoi verificarlo tramite:

sudo env PATH="$PATH" env | grep ^PATH

Vedi anche: Come sudoconservare $PATH?

Un altro motivo per cui l'ambiente potrebbe essere diverso sudoè perché potresti avere l' env_resetopzione abilitata nel tuo sudoersfile. Questo fa sì che i comandi vengano eseguiti con un nuovo ambiente minimo.

Quindi puoi usare l' env_keepopzione (non raccomandato per motivi di sicurezza ) per preservare le variabili d'ambiente del tuo utente:

Defaults        env_reset
Defaults        env_keep += "PATH PYTHONPATH"

Nella maggior parte dei Linux, i programmi vengono installati tramite la gestione dei pacchetti e si ottengono aggiornamenti in modo regolare. Se installi qualcosa che elude la gestione dei pacchetti, verrà installato in / usr / local / bin (ad esempio, o ... / sbin o / opt) e non riceverà aggiornamenti regolari.

Immagino quindi che i programmi non siano considerati così sicuri e non portino in radice il PERCORSO di default.

Ho appena provato questo da solo e non ho visto il comportamento che stavi vedendo - il mio percorso è rimasto lo stesso, quindi forse la tua configurazione sudo è diversa. Se controlli man sudoersvedrai che c'è un'opzione chiamata secure_pathche reimposta PATH- sembra che questa opzione potrebbe essere stata abilitata.

Perché quando lo usi sudo bash, bashnon funziona come una shell di login. Riprova con sudo bash -le dovresti vedere lo stesso risultato di su -.

Se questo è corretto, allora la differenza PATHsta nel file di configurazione: /etc/profile, ~/.bash_profile, ~/.bash_login, ~/.profilevengono eseguite (in questo ordine) per una shell di login, mentre ~/.bashrcviene eseguita per una shell interattiva non di login.

Vecchia domanda, lo so, ma sono inciampato qui proprio ora perché stavo indagando su questo esatto problema.

Per qualche ragione /usr/local/binera solo nel PERCORSO quando si diventa root via sudo su -. Durante l'utilizzo sudo -inon c'era. Ovviamente ora so che posso aggiungerlo a / etc / sudoers, ma ciò non ha ancora spiegato perché sia ​​già lì dopo su -. Da dove viene questa parte di PATH?

Dopo molti tentativi e ricerche ho trovato la risposta:

Il percorso predefinito contenente '/ usr / local / bin' è effettivamente codificato in su (1).

Quindi nessuna configurazione pam, profilo, bashrc o altro era responsabile dell'aggiunta selettiva di questo elemento. Era sempre già lì quando suprese il controllo. E poiché sudonon invoca suaffatto ma utilizza la propria configurazione, mancava doposudo -i

Ho trovato che questo è vero su RHEL6 e RHEL7. Non ho verificato alcuna altra versione o distribuzione.