Perché sudo cambia il PERCORSO?

Questa è la PATHvariabile senza sudo:

$ echo 'echo $PATH' | sh 
/opt/local/ruby/bin:/usr/bin:/bin

Questa è la PATHvariabile con sudo:

$ echo 'echo $PATH' | sudo sh
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin

Per quanto posso dire, sudodovrebbe lasciare PATHintatto. Cosa sta succedendo? Come lo cambio? (Questo è su Ubuntu 8.04).

AGGIORNAMENTO: per quanto posso vedere, nessuno degli script è stato avviato come modifica di root PATHin alcun modo.

Da man sudo:

Per evitare lo spoofing dei comandi, sudo controlla ``. '' E `` '' (entrambi che indicano la directory corrente) per ultimi quando cercano un comando nel PERCORSO dell'utente (se uno o entrambi sono nel PERCORSO). Si noti, tuttavia, che la variabile d'ambiente PATH effettiva non viene modificata e viene passata invariata al programma che sudo esegue.

Questo è una funzione fastidiosa una caratteristica di sudo su molte distribuzioni.

Per aggirare questo "problema" su Ubuntu, nel mio ~ / .bashrc faccio quanto segue

alias sudo='sudo env PATH=$PATH'

Nota quanto sopra funzionerà per i comandi che non ripristinano $ PATH stessi. Comunque `su 'ripristina è $ PATH, quindi devi usare -p per dirgli di non farlo. IE:

sudo su -p

Nel caso qualcun altro corre attraverso questo e vuole semplicemente disabilitare tutte le variabili di percorso cambiando per tutti gli utenti.
Accedere al file sudoers utilizzando il comando: visudo. Dovresti vedere la seguente riga da qualche parte:

Predefiniti env_reset

al quale dovresti aggiungere quanto segue nella riga successiva

Predefiniti! Percorso_sicuro

secure_path è abilitato per impostazione predefinita. Questa opzione specifica cosa fare $ PATH durante il sudoing. Il punto esclamativo disabilita la funzione.

PATH è una variabile d'ambiente e come tale è di default resettata da sudo.

È necessario disporre di autorizzazioni speciali per farlo.

A partire dal man sudo

       -E L' opzione -E (preserva ambiente) sovrascriverà env_reset
           opzione in sudoers (5)). È disponibile solo quando la corrispondenza-
           Il comando ing ha il tag SETENV o l'opzione setenv è impostata in sudo-
           ERS (5).

       È inoltre possibile trasmettere le variabili di ambiente da impostare per il comando
       la riga di comando sotto forma di VAR = valore, ad esempio
        LD_LIBRARY_PATH = / usr / local / pkg / lib. Variabili passate sul comando
       la linea è soggetta alle stesse restrizioni delle normali variazioni ambientali
       capace con un'importante eccezione. Se l'opzione setenv è impostata in
       sudoers, il comando da eseguire ha il tag SETENV impostato o il comando
       abbinato è TUTTO, l'utente può impostare variabili che sarebbero eccessivamente for-
       bidden. Vedi sudoers (5) per maggiori informazioni.

Un esempio di utilizzo:

cat >> test.sh
env | grep "MYEXAMPLE" ;
^D

sh test.sh 
MYEXAMPLE=1 sh test.sh
# MYEXAMPLE=1
MYEXAMPLE=1 sudo sh test.sh 
MYEXAMPLE=1 sudo MYEXAMPLE=2 sh test.sh 
# MYEXAMPLE=2

aggiornare

man 5 sudoers: 

     env_reset Se impostato, sudo ripristinerà l'ambiente per contenere solo
                       LOGNAME, SHELL, USER, USERNAME e le varietà SUDO_ *
                       Ables. Qualsiasi variabile nell'ambiente del chiamante
                       corrisponde agli elenchi env_keep e env_check vengono quindi aggiunti.
                       Il contenuto predefinito di env_keep e env_check
                       gli elenchi vengono visualizzati quando sudo viene eseguito da root con il
                       -V opzione. Se sudo è stato compilato con SECURE_PATH
                       opzione, il suo valore verrà utilizzato per l'ambiente PATH
                       variabile. Questo flag è attivo per impostazione predefinita.

Quindi potrebbe essere necessario verificare che questo sia / non sia compilato.

È di default in Gentoo

# ( From the build Script )
....
ROOTPATH=$(cleanpath /bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/opt/bin${ROOTPATH:+:${ROOTPATH}})
....
econf --with-secure-path="${ROOTPATH}" 

Sembra che questo bug sia in circolazione da un po 'di tempo! Ecco alcuni riferimenti di bug che potresti trovare utili (e che potresti voler sottoscrivere / votare, suggerire, suggerire ...):

Debian bug # 85123 ("sudo: SECURE_PATH non può ancora essere sovrascritto") (dal 2001!)

Sembra che Bug # 20996 sia ancora presente in questa versione di sudo. Il log delle modifiche dice che può essere ignorato in fase di esecuzione ma non ho ancora scoperto come.

Dicono di mettere qualcosa del genere nel tuo file sudoers:

Defaults secure_path="/bin:/usr/bin:/usr/local/bin"

ma quando lo faccio almeno in Ubuntu 8.10, mi dà questo errore:

visudo: unknown defaults entry `secure_path' referenced near line 10

Bug Ubuntu # 50797 ("sudo creato con --with-secure-path è problematico")

Peggio ancora, per quanto ne so, è impossibile rispecificare secure_path nel file sudoers. Quindi, se, ad esempio, vuoi offrire ai tuoi utenti un facile accesso a qualcosa sotto / opt, devi ricompilare sudo.

---

Sì. Ci deve essere un modo per ignorare questa "caratteristica" senza dover ricompilare. Niente di peggio dei bigotti della sicurezza che ti dicono cosa è meglio per il tuo ambiente e quindi non ti danno un modo per spegnerlo.

---

Questo è davvero fastidioso. Potrebbe essere saggio mantenere il comportamento attuale di default per motivi di sicurezza, ma dovrebbe esserci un modo per sovrascriverlo diverso dalla ricompilazione dal codice sorgente! Molte persone hanno bisogno dell'eredità PATH. Mi chiedo perché nessun manutentore lo abbia esaminato, il che sembra facile trovare una soluzione accettabile.

---

Ci ho lavorato attorno così:

mv /usr/bin/sudo /usr/bin/sudo.orig

quindi creare un file / usr / bin / sudo contenente quanto segue:

#!/bin/bash
/usr/bin/sudo.orig env PATH=$PATH "$@"

allora il tuo sudo normale funziona proprio come il sudo non sicuro

Bug Ubuntu # 192651 ("il percorso sudo viene sempre resettato")

Dato che un duplicato di questo bug è stato originariamente archiviato nel luglio 2006, non sono chiaro da quanto tempo è in funzione un sistema operativo inefficace. Qualunque sia il merito di costringere gli utenti a utilizzare trucchi come quello sopra elencato, sicuramente le pagine man per sudo e sudoer dovrebbero riflettere il fatto che le opzioni per modificare il PERCORSO sono effettivamente ridondanti.

La modifica della documentazione per riflettere l'esecuzione effettiva non è destabilizzante e molto utile.

Bug Ubuntu # 226595 ("impossibile conservare / specificare PERCORSO")

Devo essere in grado di eseguire sudo con ulteriori cartelle binarie non standard nel PERCORSO. Avendo già aggiunto i miei requisiti a / etc / environment, sono rimasto sorpreso quando ho ricevuto errori sui comandi mancanti durante l'esecuzione su sudo .....

Ho provato quanto segue per risolvere questo problema senza successo:

1. Utilizzando l' sudo -Eopzione " " - non ha funzionato. Il mio PATH esistente è stato ancora ripristinato da sudo

2. Cambiare " Defaults env_reset" in " Defaults !env_reset" in / etc / sudoers - inoltre non ha funzionato (anche se combinato con sudo -E)

3. Uncommenting env_reset(es. " #Defaults env_reset") In / etc / sudoers - inoltre non ha funzionato.

4. L'aggiunta di ' Defaults env_keep += "PATH"' a / etc / sudoers - inoltre non ha funzionato.

Chiaramente - nonostante la documentazione man - sudo è completamente hardcoded per quanto riguarda PATH e non consente alcuna flessibilità riguardo al mantenimento degli utenti PATH. Molto fastidioso perché non riesco a eseguire software non predefinito con i permessi di root usando sudo.

Questo sembra funzionare per me

sudo -i 

che assume il non-sudo PATH

Penso che in effetti sia desiderabile avere sudo resettato il PERCORSO: altrimenti un utente malintenzionato che ha compromesso il tuo account utente potrebbe mettere sul retro dei percorsi degli utenti versioni backdoor di tutti i tipi di strumenti e verrebbero eseguiti quando si usa sudo.

(ovviamente avere sudo resettato il PERCORSO non è una soluzione completa a questo tipo di problemi, ma aiuta)

Questo è davvero ciò che accade quando lo usi

Defaults env_reset

in / etc / sudoers senza usare exempt_groupo env_keep.

Ciò è utile anche perché è possibile aggiungere directory utili solo per root (come /sbine /usr/sbin) al percorso sudo senza aggiungerle ai percorsi degli utenti. Per specificare il percorso utilizzato da sudo:

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

Funziona ora usando sudo dai repository karmici. Dettagli dalla mia configurazione:

root@sphinx:~# cat /etc/sudoers | grep -v -e '^$' -e '^#'
Defaults    env_reset
Defaults    secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/grub-1.96/sbin:/opt/grub-1.96/bin"
root    ALL=(ALL) ALL
%admin ALL=(ALL) ALL
root@sphinx:~# cat /etc/apt/sources.list
deb http://au.archive.ubuntu.com/ubuntu/ jaunty main restricted universe
deb-src http://au.archive.ubuntu.com/ubuntu/ jaunty main restricted universe

deb http://au.archive.ubuntu.com/ubuntu/ jaunty-updates main restricted universe
deb-src http://au.archive.ubuntu.com/ubuntu/ jaunty-updates main restricted universe

deb http://security.ubuntu.com/ubuntu jaunty-security main restricted universe
deb-src http://security.ubuntu.com/ubuntu jaunty-security main restricted universe

deb http://au.archive.ubuntu.com/ubuntu/ karmic main restricted universe
deb-src http://au.archive.ubuntu.com/ubuntu/ karmic main restricted universe

deb http://au.archive.ubuntu.com/ubuntu/ karmic-updates main restricted universe
deb-src http://au.archive.ubuntu.com/ubuntu/ karmic-updates main restricted universe

deb http://security.ubuntu.com/ubuntu karmic-security main restricted universe
deb-src http://security.ubuntu.com/ubuntu karmic-security main restricted universe
root@sphinx:~# 

root@sphinx:~# cat /etc/apt/preferences 
Package: sudo
Pin: release a=karmic-security
Pin-Priority: 990

Package: sudo
Pin: release a=karmic-updates
Pin-Priority: 960

Package: sudo
Pin: release a=karmic
Pin-Priority: 930

Package: *
Pin: release a=jaunty-security
Pin-Priority: 900

Package: *
Pin: release a=jaunty-updates
Pin-Priority: 700

Package: *
Pin: release a=jaunty
Pin-Priority: 500

Package: *
Pin: release a=karmic-security
Pin-Priority: 450

Package: *
Pin: release a=karmic-updates
Pin-Priority: 250

Package: *
Pin: release a=karmic
Pin-Priority: 50
root@sphinx:~# apt-cache policy sudo
sudo:
  Installed: 1.7.0-1ubuntu2
  Candidate: 1.7.0-1ubuntu2
  Package pin: 1.7.0-1ubuntu2
  Version table:
 *** 1.7.0-1ubuntu2 930
         50 http://au.archive.ubuntu.com karmic/main Packages
        100 /var/lib/dpkg/status
     1.6.9p17-1ubuntu3 930
        500 http://au.archive.ubuntu.com jaunty/main Packages
root@sphinx:~# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/opt/grub-1.96/sbin:/opt/grub-1.96/bin
root@sphinx:~# exit
exit
abolte@sphinx:~$ echo $PATH
/home/abolte/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/opt/grub-1.96/sbin:/opt/grub-1.96/bin:/opt/chromium-17593:/opt/grub-1.96/sbin:/opt/grub-1.96/bin:/opt/xpra-0.0.6/bin
abolte@sphinx:~$ 

È meraviglioso averlo finalmente risolto senza usare un hack.

# cat .bash_profile | grep PATH
PATH=$HOME/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin
export PATH

# cat /etc/sudoers | grep Defaults
Defaults    requiretty
Defaults    env_reset
Defaults    env_keep = "SOME_PARAM1 SOME_PARAM2 ... PATH"

Basta commentare "Predefiniti env_reset" in / etc / sudoers

Modifica env_keepin/etc/sudoers

Sembra qualcosa del genere:

Defaults env_keep = "LANG LC_ADDRESS LC_CTYPE LC_COLLATE LC_IDENTIFICATION LC_MEASURE MENT LC_MESSAGES LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE LC_TIME LC_ALL L ANGUAGE LINGUAS XDG_SESSION_COOKIE"

Basta aggiungere PATH alla fine, quindi dopo la modifica sembrerebbe così:

Defaults env_keep = "LANG LC_ADDRESS LC_CTYPE LC_COLLATE LC_IDENTIFICATION LC_MEASURE MENT LC_MESSAGES LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE LC_TIME LC_ALL L ANGUAGE LINGUAS XDG_SESSION_COOKIE PATH"

Chiudere il terminale e quindi riaprirlo.

Secure_path è tuo amico, ma se vuoi esentarti da secure_path, fallo

sudo visudo

E append

Predefiniti hext_group = your_goup

Se vuoi esentare un gruppo di utenti crea un gruppo, aggiungi tutti gli utenti e usalo come gruppo_exnt. man 5 sudoers per di più.

la soluzione consigliata nei commenti sulla distro OpenSUSE suggerisce di cambiare:

Defaults env_reset

per:

Defaults !env_reset

e quindi presumibilmente commentare la seguente riga che non è necessaria:

Defaults env_keep = "LANG LC_ADDRESS LC_CTYPE LC_COLLATE LC_IDENTIFICATION LC_MEASURE    MENT LC_MESSAGES LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE LC_TIME LC_ALL L    ANGUAGE LINGUAS XDG_SESSION_COOKIE"

commentare sia "Default env_reset" che "Default secure_path ..." nel file / etc / sudores funziona per me

Puoi anche spostare il tuo file in una directory usata sudoers:

    sudo mv $HOME/bash/script.sh /usr/sbin/ 

Ehm, non è davvero un test se non aggiungi qualcosa al tuo percorso:

bill @ bill-desktop: ~ $ ls -l / opt / pkg / bin
totale 12
-rwxr-xr-x 1 radice radice 28 2009-01-22 18:58 foo
bill @ bill-desktop: ~ $ che foo
/ Opt / pkg / bin / foo
bill @ bill-desktop: ~ $ sudo su
root @ bill-desktop: / home / bill # quale pippo
root @ disegno di legge-desktop: / home / fattura # 

Il PATH verrà resettato quando si usa su o sudo dalla definizione di ENV_SUPATH, e ENV_PATH definito in /etc/login.defs

$ PATH è una variabile d'ambiente e significa che il valore di $ PATH può differire per un altro utente.

Quando esegui l'accesso al tuo sistema, le impostazioni del tuo profilo decidono il valore di $ PATH .

Ora diamo un'occhiata: -

User       |        Value of $PATH
--------------------------
root                /var/www
user1               /var/www/user1
user2               /var/www/html/private

Supponiamo che questi siano i valori di $ PATH per diversi utenti. Ora, quando si esegue un comando con sudo, nel vero senso l' utente root esegue quel comando.

È possibile confermare eseguendo questi comandi sul terminale: -

user@localhost$ whoami
username
user@localhost$ sudo whoami
root
user@localhost$ 

Questo è il motivo. Penso che sia chiaro per te.