Przez lata na systemach typu UNIX (najbardziej dla mnie, Linuksa) zauważyłem, że .(obecny katalog) nigdy nie jest $PATHdomyślnie ustawiony . Dlaczego to?
Pamiętam, jak czytałem lata temu, że był to problem z bezpieczeństwem, ale artykuł, który przeczytałem, nie wyjaśnił, na czym dokładnie polega problem. Czy to dlatego, że ktoś mógł zostawić złośliwą wersję katalogu lslub cpw katalogu, a skończyło się na tym, że nie wiedziałem, że tam jest?
Odpowiedzi:
Odpowiedziałeś poprawnie na swoje pytanie, właśnie dlatego kropka nie jest na ścieżce: w
celu ochrony przed dziecięcymi wirusami lub uczciwymi błędami.
Oczywiście jest to bardzo kiepski i bezużyteczny środek antywirusowy i nic nie powstrzymuje cię przed dodaniem kropki do ścieżki.
-rfw katalogu ( rm *ciekawe) ;-)
-rf? ;)
Tak. Jeśli wstawisz „.” na ścieżce skończyłoby się wysyłaniem wielu wywołań poleceń do plików w bieżącym katalogu.
Nawet jeśli był ostatni, nadal występuje błąd pilota. Na przykład w Solarisie 10 brakuje „góry”. Piszę „top” w moim systemie przez cały dzień, ponieważ myślę, że jestem w systemie, który ma „top”.
Przepraszam, chciałbym o to zapytać w formie komentarza do wybranej odpowiedzi, ale nie mam jeszcze żadnego przedstawiciela superużytkownika.
Odpowiedź bezpieczeństwa ma sens, ale jeśli wpiszesz „.” w swojej ŚCIEŻCE jako ostatnia rzecz, czy powłoka nie powinna wyglądać w bieżącym katalogu podczas wyszukiwania plików wykonywalnych, a tym samym zmniejszyć ryzyko bezpieczeństwa? Gdyby przeszukiwał $ PATH w kolejności, znalazłby / bin / ls zanim znalazłby ./ls.
Jak niepewne jest dla mnie umieszczenie „”. na końcu mojej zmiennej środowiskowej $ PATH?
Działa jak sugeruję. Oto jak testowałem:
Najpierw dodaj „.” na KONIEC zmiennej środowiskowej PATH.
Następnie umieść następujący plik w jakimś katalogu, takim jak ~ / dir1 / dir2 / test_which.rb:
#!/your/path/to/ruby
puts "this file is from the current directory"
I umieść ten plik na /usr/bin/test_which.rb
#!/your/path/to/ruby
puts "this file is at /usr/bin/test_which.rb"
Pamiętaj, aby chmod + x pliki, aby były one wykonywalne.
Teraz, jeśli zmienisz katalog na ~ / dir1 / dir2 i wykonasz test_which.rb, otrzymasz wynik
this file is at /usr/bin/test_which.rbRzeczywiście, jeśli uruchomisz „który test_which.rb” z dowolnego miejsca, powinien to zgłosić
/usr/bin/test_which.rbNadal możesz wykonać plik w bieżącym katalogu, wpisując:
./test_which.rbdci slczy sduow powłoce i został uratowany przez „nie znaleziono polecenia”. Zawsze.
ls(wydruk w kolorze i więcej) alias, do lktórej zrezygnowałem całkowicie z literówek.
Więcej niż ryzyko bezpieczeństwa, mając „.” w ŚCIEŻCE sprawiają, że prawie niemożliwe jest upewnienie się, że wykonanie dowolnego polecenia działa zgodnie z przeznaczeniem. Pomyśl o uruchomieniu polecenia typu „zip” w ogromnym katalogu zawierającym tysiące plików o losowych nazwach. Możliwość, że jedna z nich faktycznie nazywa się „zip”, nie jest nieistotna i doprowadziłaby do bardzo trudnego do zrozumienia błędu (w rzeczywistości plik powinien być wykonywalny, co jednak może się zdarzyć).
W szczególności dotyczy to pisania skryptów, które zachowują zmienną PATH użytkownika. Dobry napisany skrypt powinien zajmować się wszystkimi przypadkami narożnymi (jak nazwy plików ze spacjami lub zaczynającymi się od „-”). Ale niepraktyczne jest zapobieganie wykonywaniu pliku w bieżącym katalogu zamiast polecenia systemowego ...
lsbędzie/usr/bin/lsi./lstak nie będzie. Problemem jest również to, że jeśli wiesz, jak dodać.do końca swojej ścieżki, prawdopodobnie masz pojęcie, co robisz. root nigdy nie powinien mieć.na ścieżce, wiele systemów nawet nie pozwala logować się rootowi.