Dlaczego zmienne PATH różnią się podczas uruchamiania przez sudo i su?

Na mojej maszynie fedora, gdy działam z moim kontem użytkownika, mam /usr/local/binna swojej ścieżce:

[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

Podobnie podczas uruchamiania 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

Jednak podczas uruchamiania przez sudoten katalog nie znajduje się na ścieżce:

[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

Dlaczego ścieżka miałaby być inna podczas biegania przez sudo?

Spójrz na /etc/sudoers. Domyślny plik w Fedorze (jak również w RHEL, a także w Ubuntu i podobnych) zawiera ten wiersz:

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

Co zapewnia czystość ścieżki podczas uruchamiania plików binarnych w sudo. Pomaga to chronić przed niektórymi obawami wymienionymi w tym pytaniu . Jest to również wygodne, jeśli nie masz /sbini /usr/sbinze swojej własnej drogi.

Polecenie su -wykona profil użytkownika root i przejmie środowisko tego użytkownika, w tym ścieżka itp. Tego sudonie robi.

Jeśli chcesz się tak sudozachowywać, su -skorzystaj z opcji, sudo -i [commandktóra uruchomi profil użytkownika

Jeśli chcesz się tak su -zachowywać sudo, nie używaj łącznika - po prostu użyjsu [command]

Możesz sprawdzić, dlaczego (jest inaczej), uruchamiając sudo sudo -V.

Na przykład w systemie Linux:

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

^{Uwaga: Na MacOS / BSD, wystarczy uruchomić: sudo sudo -V.}

Powyższa lista jest ograniczona z powodu domyślnej wtyczki zasad bezpieczeństwa w niektórych dystrybucjach Linuksa.

Jest to wyjaśnione dalej w man sudoers:

Jeśli secure_pathopcja jest ustawiona, jej wartość zostanie wykorzystana dla PATHzmiennej środowiskowej.

secure_path- Ścieżka używana dla każdego polecenia uruchamianego z sudo. Jeśli nie ufasz, że osoby uruchamiające sudo mają rozsądną PATHzmienną środowiskową, możesz chcieć tego użyć.

Innym zastosowaniem jest, jeśli chcesz, aby „ścieżka katalogu głównego” była oddzielna od „ścieżki użytkownika”. Użytkownicy w grupie określonej przez exempt_groupopcję nie mają wpływu secure_path. Ta opcja nie jest domyślnie ustawiona.

W takim przypadku możesz to zmienić, uruchamiając sudo visudoi edytując plik konfiguracyjny i modyfikując secure_path(dodając dodatkową ścieżkę oddzieloną przez :) lub dodając użytkownika do exempt_group(aby secure_pathopcje nie wpłynęły na ciebie ).

Lub w celu przejścia użytkownika PATHtymczasowego, możesz uruchomić:

sudo env PATH="$PATH" my_command

i możesz to sprawdzić poprzez:

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

Zobacz także: Jak sudozachować $PATH?

Innym powodem, dla którego środowisko może być inne sudo, jest to, że możesz mieć env_resetwłączoną opcję w swoim sudoerspliku. To powoduje, że polecenia są wykonywane w nowym, minimalnym środowisku.

Możesz więc użyć env_keepopcji (niezalecanej ze względów bezpieczeństwa ), aby zachować zmienne środowiskowe użytkownika:

Defaults        env_reset
Defaults        env_keep += "PATH PYTHONPATH"

W większości linuksów instalujesz programy za pomocą zarządzania pakietami i regularnie otrzymujesz aktualizacje. Jeśli zainstalujesz coś, co obchodzi zarządzanie pakietami, zostanie ono zainstalowane w / usr / local / bin (na przykład lub ... / sbin lub / opt) i nie będzie otrzymywać regularnych aktualizacji.

Wydaje mi się, że dlatego programy nie są uważane za tak bezpieczne i domyślnie nie są umieszczane w katalogu głównym PATH.

Właśnie to wypróbowałem i nie widziałem zachowania, które widziałeś - moja ścieżka pozostała taka sama, więc może twoja konfiguracja sudo jest inna. Jeśli sprawdzisz man sudoers, zobaczysz, że istnieje opcja o nazwie secure_pathresetująca PATH- wygląda na to, że ta opcja mogła być włączona.

Ponieważ kiedy używasz sudo bash, bashnie działa jako powłoka logowania. Spróbuj ponownie, sudo bash -la powinieneś zobaczyć ten sam wynik jak su -.

Jeśli to prawda, to różnica PATHpolega na plikach konfiguracyjnych: /etc/profile, ~/.bash_profile, ~/.bash_login, ~/.profilesą wykonywane (w tej kolejności) na powłokę logowania, gdy ~/.bashrcjest wykonywany na zakaz logowania interaktywnej powłoki.

Stare pytanie, wiem, ale natknąłem się tutaj właśnie teraz, ponieważ badałem dokładnie ten problem.

Z jakiegoś powodu /usr/local/binznajdował się tylko w ŚCIEŻCE podczas rootowania sudo su -. Podczas korzystania sudo -inie było go. Oczywiście teraz wiem, że mogę dodać go do / etc / sudoers, ale to wciąż nie wyjaśnia, dlaczego już tam jest su -. Skąd ta część ŚCIEŻKI?

Po wielu poszukiwaniach i wyszukiwaniu znalazłem odpowiedź:

Domyślna ścieżka zawierająca „/ usr / local / bin” jest tak naprawdę zakodowana w su (1).

Tak więc żadna konfiguracja pam, profil, bashrc ani nic innego nie było odpowiedzialne za selektywne dodawanie tego elementu. Kiedyś został przejęty su. A ponieważ w sudoogóle nie wywołuje, suale używa własnej konfiguracji, po tym brakowałosudo -i

Stwierdziłem, że tak jest w przypadku RHEL6 i RHEL7. Nie sprawdziłem żadnej innej wersji ani dystrybucji.