Dlaczego sudo zmienia ŚCIEŻKĘ?

281

To jest PATHzmienna bez sudo:

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

To jest PATHzmienna z sudo:

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

O ile wiem, sudoma pozostawiać PATHnietknięte. Co się dzieje? Jak to zmienić? (To jest na Ubuntu 8.04).

AKTUALIZACJA: o ile widzę, żaden ze skryptów nie rozpoczął się jako zmiana roota PATHw jakikolwiek sposób.

Od man sudo:

Aby zapobiec fałszowaniu poleceń, sudo sprawdza ostatnie ``. '' I `` '' (oba oznaczają bieżący katalog) podczas wyszukiwania polecenia w ŚCIEŻCE użytkownika (jeśli jedno lub oba znajdują się w ŚCIEŻCE). Należy jednak pamiętać, że rzeczywista zmienna środowiskowa PATH nie jest modyfikowana i jest przekazywana bez zmian do programu uruchamianego przez sudo.

Michiel de Mare
źródło
Czy root ma coś, co ustawia PATH w .bashrc? Zakłada się, że skoro jesteś na Linuksie, sh jest naprawdę bash.
Greg Hewgill

Odpowiedzi:

241

To jest irytująca funkcja cecha sudo w wielu dystrybucjach.

Aby obejść ten „problem” na Ubuntu, wykonaj następujące czynności w moim ~ / .bashrc

alias sudo='sudo env PATH=$PATH'

Uwaga: powyższe będzie działać dla poleceń, które same nie resetują zmiennej $ PATH. Jednak `su 'resetuje zmienną $ PATH, więc musisz użyć -p, aby powiedzieć jej, żeby tego nie robiła. TO ZNACZY:

sudo su -p
pixelbeat
źródło
46
Ta „irytująca funkcja” zapobiega trojanowi. Mówię, że wymuszenie określonej $ PATH jest funkcją, a nie błędem --- powoduje, że zapisujesz pełną ścieżkę do programu, który jest poza $ PATH.
Chris Jester-Young
29
Tak, ale to całkowicie sprzeczne z intuicją. Prawdopodobnie oszuka dobrych ludzi bardziej niż złych.
Brian Armstrong,
31
Jest to nie tylko sprzeczne z intuicją, ale niepoprawnie udokumentowane. Czytając strony podręcznika sudo i porównując konfigurację z polem Fedory, pomyślałem, że ścieżka powinna zostać zachowana. Rzeczywiście, „sudo -V” mówi nawet „Zmienne środowiskowe do zachowania: PATH”.
Jason R. Coombs
6
to denerwujące. Kropka. gdyby mógł „trojaned” przez sudo, bez niego mógłby zostać trojanowany. przyznane, trudniejsze, ale jeśli uruchamiasz kod z niewłaściwego miejsca, nawet ze swoim zwykłym użytkownikiem, sprawy są już wystarczająco złe.
gcb
7
Nie pseudonim sudo; zobacz odpowiedź @Jacob na temat ustawień domyślnych env_reset.
greg_1_anderson
121

W przypadku, gdy ktoś inny działa przez to i chce po prostu wyłączyć wszystkie zmiany zmiennych ścieżki dla wszystkich użytkowników.
Dostęp do pliku sudoers za pomocą polecenia: visudo. Powinieneś zobaczyć gdzieś następującą linię:

Domyślnie env_reset

które należy dodać w następnym wierszu

Domyślnie! Ścieżka_bezpieczna

ścieżka_bezpieczna jest domyślnie włączona. Ta opcja określa, co zrobić $ PATH podczas sudo. Wykrzyknik wyłącza tę funkcję.

Jakub
źródło
6
inny sposób:Defaults env_keep = "PATH"
gcb
1
Domyślnie! Secure_path działało dla mnie świetnie na nowoczesnych systemach; na starym polu Ubuntu 8.04, Defaults env_keep = "PATH" załatwiło sprawę.
greg_1_anderson
29
Zamiast wyłączać ścieżkę bezpieczeństwa, możesz do niej dodać. Na przykład w moim przypadku dodałem wiersz „Domyślnie ścieżka_bezpieczna = / sbin: / bin: / usr / sbin: / usr / bin: / some / custom / directory” gdzie „some / custom / directory” to ścieżka, której potrzebowałem udostępnić sudo.
Hector Correa
Rozwiązanie @HectorCorrea to lepszy sposób IMO.
chakrit
32

PATH jest zmienną środowiskową i jako taka jest domyślnie resetowana przez sudo.

Aby to zrobić, potrzebujesz specjalnych uprawnień.

Z man sudo

       -E Opcja -E (zachowanie środowiska) zastąpi ustawienie env_reset
           opcja w sudoers (5)). Jest dostępny tylko wtedy, gdy albo
           Komenda ing ma znacznik SETENV lub opcję setenv ustawiono w sudo-
           ers (5).
       Zmienne środowiskowe, które należy ustawić dla polecenia, mogą być również przekazywane
       wiersz poleceń w postaci VAR = wartość, np.
        LD_LIBRARY_PATH = / usr / local / pkg / lib. Zmienne przekazane do polecenia
       linie podlegają tym samym ograniczeniom, co normalne warunki otoczenia
       z jednym ważnym wyjątkiem. Jeśli ustawiono opcję setenv
       sudoers, polecenie do uruchomienia ma ustawiony znacznik SETENV lub polecenie
       dopasowane jest WSZYSTKIE, użytkownik może ustawić zmienne, które w przeciwnym razie byłyby dla-
       zabronione. Aby uzyskać więcej informacji, zobacz sudoers (5).

Przykład użycia:

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

aktualizacja

mężczyzna 5 sudoers: 

     env_reset Jeśli jest ustawiony, sudo zresetuje środowisko, aby zawierało tylko
                       LOGNAME, SHELL, USER, USERNAME i SUDO_ *
                       umiejętności Wszelkie zmienne w środowisku dzwoniącego, które
                       dopasuj env_keep, a następnie zostaną dodane listy env_check.
                       Domyślna zawartość env_keep i env_check
                       listy są wyświetlane, gdy sudo jest uruchamiane przez root za pomocą
                       -V opcja. Jeśli sudo zostało skompilowane z SECURE_PATH
                       opcja, jej wartość zostanie wykorzystana w środowisku PATH
                       zmienna. Ta flaga jest domyślnie włączona.

Może więc zajść potrzeba sprawdzenia, czy to nie jest / nie jest skompilowane.

Domyślnie jest w 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}" 
Kent Fredric
źródło
17

Wygląda na to, że ten błąd występuje już od dłuższego czasu! Oto kilka odniesień do błędów, które mogą Ci się przydać (i możesz chcieć zasubskrybować / zagłosować, wskazówkę, wskazówkę ...):


Błąd Debiana # 85123 („sudo: SECURE_PATH nadal nie można zastąpić”) (od 2001 roku!)

Wygląda na to, że Bug # 20996 jest nadal obecny w tej wersji sudo. Dziennik zmian mówi, że można go zmienić w czasie wykonywania, ale jeszcze nie odkryłem, jak to zrobić.

Wspominają o umieszczeniu czegoś takiego w pliku sudoers:

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

ale gdy robię to przynajmniej w Ubuntu 8.10, pojawia się następujący błąd:

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

Błąd Ubuntu # 50797 („Problem z sudo zbudowanym z --with-secure-path jest problematyczny”)

Co gorsza, o ile mogę stwierdzić, nie można ponownie podać ścieżki bezpiecznej w pliku sudoers. Jeśli na przykład chcesz zaoferować użytkownikom łatwy dostęp do czegoś w / opt, musisz ponownie skompilować sudo.


Tak. Tam musi być jakiś sposób, aby zastąpić tę „funkcję” bez konieczności rekompilacji. Nie ma nic gorszego niż bigoty bezpieczeństwa, które mówią ci, co jest najlepsze dla twojego środowiska, a następnie nie dają ci możliwości ich wyłączenia.


To jest naprawdę denerwujące. Rozsądnie byłoby zachować domyślne zachowanie ze względów bezpieczeństwa, ale powinien istnieć sposób zastąpienia go innym niż rekompilacja z kodu źródłowego! Wiele osób potrzebuje dziedziczenia ŚCIEŻKOWEGO. Zastanawiam się, dlaczego żaden opiekun nie zagląda w to, co wydaje się łatwe do znalezienia dopuszczalnego rozwiązania.


Pracowałem nad tym w ten sposób:

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

następnie utwórz plik / usr / bin / sudo zawierający następujące elementy:

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

wtedy zwykłe sudo działa podobnie jak sudo niezabezpieczone


Błąd Ubuntu # 192651 („Ścieżka sudo jest zawsze resetowana”)

Biorąc pod uwagę, że duplikat tego błędu został pierwotnie złożony w lipcu 2006 r., Nie jestem pewien, jak długo działała nieefektywna funkcja env_keep. Bez względu na zalety zmuszania użytkowników do korzystania ze sztuczek, takich jak te wymienione powyżej, z pewnością strony podręcznika dla sudo i sudoers powinny odzwierciedlać fakt, że opcje modyfikacji PATH są faktycznie zbędne.

Modyfikacja dokumentacji w celu odzwierciedlenia faktycznego wykonania nie jest destabilizująca i bardzo pomocna.


Błąd Ubuntu # 226595 („niemożliwe do zachowania / określenia ŚCIEŻKA”)

Muszę być w stanie uruchamiać sudo z dodatkowymi folderami binarnymi niestartymi w PATH. Po dodaniu moich wymagań do / etc / environment byłem zaskoczony, gdy otrzymałem błędy dotyczące brakujących poleceń podczas uruchamiania ich w sudo .....

Próbowałem rozwiązać ten problem bez powodzenia:

  1. Korzystanie z sudo -Eopcji „ ” - nie działało. Moja istniejąca ŚCIEŻKA została zresetowana przez sudo

  2. Zmiana „ Defaults env_reset” na „ Defaults !env_reset” w / etc / sudoers - również nie działała (nawet w połączeniu z sudo -E)

  3. Odkomentowanie env_reset(np. „ #Defaults env_reset”) W / etc / sudoers - również nie działało.

  4. Dodanie „ Defaults env_keep += "PATH"” do / etc / sudoers - również nie działało.

Najwyraźniej - pomimo dokumentacji man - sudo jest całkowicie zakodowane w odniesieniu do ŚCIEŻKI i nie zapewnia żadnej elastyczności w zakresie zatrzymywania ŚCIEŻKI użytkownika. Bardzo denerwujące, ponieważ nie mogę uruchamiać oprogramowania innego niż domyślny na podstawie uprawnień roota za pomocą sudo.

Tyler Rick
źródło
13

Wydawało mi się, że to działa

sudo -i 

która bierze na siebie nie sudo PATH

axsuul
źródło
„sudo -i” nie pomaga w Ubuntu (sprawdziłem Ubuntu 14.04.3 LTS). $ PATH jest nadal modyfikowany przez sudo.
Marcin Raczyński
11

Myślę, że w rzeczywistości pożądane jest, aby sudo zresetowało ŚCIEŻKĘ: w przeciwnym razie atakujący, który naruszył twoje konto użytkownika, może umieścić w wersji ŚCIEŻKOWEJ wersje wszelkiego rodzaju narzędzi w ŚCIEŻCE użytkowników i zostaną one wykonane podczas korzystania z sudo.

(oczywiście reset sudo PATH nie jest kompletnym rozwiązaniem tego rodzaju problemów, ale pomaga)

Tak właśnie dzieje się, gdy używasz

Defaults env_reset

w / etc / sudoers bez użycia exempt_grouplub env_keep.

Jest to również wygodne, ponieważ możesz dodawać katalogi, które są przydatne tylko dla roota (takie jak /sbini /usr/sbin) do ścieżki sudo bez dodawania ich do ścieżek użytkowników. Aby określić ścieżkę do użycia przez sudo:

Defaults secure_path="/bin:/usr/bin:/usr/local/bin:/sbin:/usr/sbin"
Arnout Engelen
źródło
atakujący, który uzyska dostęp do konta sudoer, może robić jeszcze gorsze rzeczy.
user508546
Przyzwoita rada. W Ubuntu 12.04 Server podobne ustawienie jest domyślne.
Tsutomu
7

Działa teraz przy użyciu sudo z repozytoriów karmicznych. Szczegóły z mojej konfiguracji:

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:~$ 

Wspaniale jest wreszcie rozwiązać ten problem bez użycia hacka.


źródło
4
Być może zastanowisz się nad przepisaniem tego, aby wskazać, jak ktoś z czystą instalacją Karmic może zaktualizować swoją konfigurację, aby rozwiązać ten konkretny problem.
Jason R. Coombs
4
# 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"
daggerok
źródło
3

Po prostu skomentuj „Defaults env_reset” w / etc / sudoers


źródło
3

Po prostu edytuj env_keepw/etc/sudoers

Wygląda to mniej więcej tak:

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"

Po prostu dołącz PATH na końcu, aby po zmianie wyglądało to tak:

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"

Zamknij terminal, a następnie otwórz ponownie.

temp_sny
źródło
Czekaj, PATH potrzebuje 2 **? Dlaczego PATH potrzebuje **?
CMCDragonkai
@CMCDragonkai Został sformatowany jako pogrubiony (w znaczniku), ale ktoś (przepełnienie stosu nie pozwoli mi wskazać palcami) edytował go, aby oznaczyć jako kod.
1j01
2

Secure_path jest twoim przyjacielem, ale jeśli chcesz zwolnić się z secure_path, po prostu zrób to

sudo visudo

I dołącz

Domyślnie exempt_group = twoja_upa

Jeśli chcesz zwolnić grupę użytkowników, stwórz grupę, dodaj do niej wszystkich użytkowników i użyj jej jako grupy_wolnej. man 5 sudoers na więcej.

użytkownik378555
źródło
1

zalecane rozwiązanie w komentarzach do dystrybucji OpenSUSE sugeruje zmianę:

Defaults env_reset

do:

Defaults !env_reset

a następnie prawdopodobnie skomentować następujący wiersz, który nie jest potrzebny:

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"
inman320
źródło
1

skomentuj zarówno „Default env_reset”, jak i „Default secure_path ...” w pliku / etc / sudores działa dla mnie

użytkownik3622173
źródło
1

Możesz także przenieść plik do katalogu używanego sudoers:

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

źródło
0

Eee, to naprawdę nie jest test, jeśli nie dodasz czegoś do swojej ścieżki:

bill @ bill-desktop: ~ $ ls -l / opt / pkg / bin
razem 12
-rwxr-xr-x 1 root root 28 2009-01-22 18:58 foo
bill @ bill-desktop: ~ $ które foo
/ opt / pkg / bin / foo
bill @ bill-desktop: ~ $ sudo su
root @ bill-desktop: / home / bill # which foo
root @ bill-desktop: / home / bill # 

źródło
0

ŚCIEŻKA zostanie zresetowana podczas używania su lub sudo zgodnie z definicją ENV_SUPATH i ENV_PATH zdefiniowaną w /etc/login.defs

Bradley Allen
źródło
0

$ PATH jest zmienną środowiskową i oznacza, że ​​wartość $ PATH może się różnić dla innych użytkowników.

Gdy logujesz się do swojego systemu, to ustawienie profilu decyduje o wartości $ PATH .

Teraz spójrzmy: -

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

Załóżmy, że są to wartości $ PATH dla różnych użytkowników. Teraz, gdy wykonujesz dowolne polecenie za pomocą sudo, w rzeczywistości oznacza to, że użytkownik root wykonuje to polecenie.

Możesz potwierdzić, wykonując następujące polecenia na terminalu:

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

To jest powód. Myślę, że to dla ciebie jasne.

Deepak Dixit
źródło