Dlaczego sudo zmienia ŚCIEŻKĘ?

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.

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

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ę.

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}" 

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.

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

sudo -i 

która bierze na siebie nie sudo PATH

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"

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.

# 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"

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

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.

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.

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"

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

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

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

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 # 

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

$ 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.