Na mojej maszynie fedora, gdy działam z moim kontem użytkownika, mam /usr/local/bin
na 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 sudo
ten 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
?
sudo
zachować $ PATH?Odpowiedzi:
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: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
/sbin
i/usr/sbin
ze swojej własnej drogi.źródło
/usr/local/bin
tę dyrektywę , zobaczyłbym ją na swojej drodze, gdy biegnęsudo
, prawda?/usr/local/bin
. Dziękuję bardzo za wyjaśnienie tego!sudo
na przykład skryptu w swojej~/bin
(lub jakiejkolwiek innej ścieżce)? Właśnie dokonałem zmiany - działa, myślałeś tylko, że może to być druga strona?Polecenie
su -
wykona profil użytkownika root i przejmie środowisko tego użytkownika, w tym ścieżka itp. Tegosudo
nie robi.Jeśli chcesz się tak
sudo
zachowywać,su -
skorzystaj z opcji,sudo -i [command
która uruchomi profil użytkownikaJeśli chcesz się tak
su -
zachowywaćsudo
, nie używaj łącznika - po prostu użyjsu [command]
źródło
Możesz sprawdzić, dlaczego (jest inaczej), uruchamiając
sudo sudo -V
.Na przykład w systemie Linux:
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
:W takim przypadku możesz to zmienić, uruchamiając
sudo visudo
i edytując plik konfiguracyjny i modyfikującsecure_path
(dodając dodatkową ścieżkę oddzieloną przez:
) lub dodając użytkownika doexempt_group
(abysecure_path
opcje nie wpłynęły na ciebie ).Lub w celu przejścia użytkownika
PATH
tymczasowego, możesz uruchomić:i możesz to sprawdzić poprzez:
Zobacz także: Jak
sudo
zachować$PATH
?Innym powodem, dla którego środowisko może być inne
sudo
, jest to, że możesz miećenv_reset
włączoną opcję w swoimsudoers
pliku. To powoduje, że polecenia są wykonywane w nowym, minimalnym środowisku.Możesz więc użyć
env_keep
opcji (niezalecanej ze względów bezpieczeństwa ), aby zachować zmienne środowiskowe użytkownika:źródło
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.
źródło
sudo
domyślnie wykluczałby ten katalog.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 nazwiesecure_path
resetującaPATH
- wygląda na to, że ta opcja mogła być włączona.źródło
Ponieważ kiedy używasz
sudo bash
,bash
nie działa jako powłoka logowania. Spróbuj ponownie,sudo bash -l
a powinieneś zobaczyć ten sam wynik jaksu -
.Jeśli to prawda, to różnica
PATH
polega na plikach konfiguracyjnych:/etc/profile
,~/.bash_profile
,~/.bash_login
,~/.profile
są wykonywane (w tej kolejności) na powłokę logowania, gdy~/.bashrc
jest wykonywany na zakaz logowania interaktywnej powłoki.źródło
Stare pytanie, wiem, ale natknąłem się tutaj właśnie teraz, ponieważ badałem dokładnie ten problem.
Z jakiegoś powodu
/usr/local/bin
znajdował się tylko w ŚCIEŻCE podczas rootowaniasudo su -
. Podczas korzystaniasudo -i
nie było go. Oczywiście teraz wiem, że mogę dodać go do / etc / sudoers, ale to wciąż nie wyjaśnia, dlaczego już tam jestsu -
. 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ż wsudo
ogóle nie wywołuje,su
ale 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.
źródło
su
binarnego, zmieniłem się/usr/local/bin
w coś innego i wywołałem kopię. Moja ŚCIEŻKA zawierała teraz zmodyfikowany ciąg ... Dobre dzieci i nie leniwi administratorzy oczywiście po prostu pobierają źródło i tam się meldują. ;-)