Trên các hệ thống giống như UNIX trong nhiều năm qua (phù hợp nhất với tôi, Linux), tôi đã nhận thấy rằng .(thư mục hiện tại) không bao giờ có trong $PATHmặc định. Tại sao lại thế này?
Tôi nhớ lại việc đọc nhiều năm trước rằng đó là một vấn đề bảo mật, nhưng bài báo tôi đọc không giải thích chính xác vấn đề là gì. Có phải vì ai đó có thể để lại một phiên bản độc hại của lshoặc cptrong một thư mục, và cuối cùng tôi sẽ chạy nó mà không nhận ra nó ở đó?
Câu trả lời:
Bạn đã trả lời đúng câu hỏi của riêng bạn, đó chính xác là lý do tại sao dấu chấm không nằm trong đường dẫn:
Để bảo vệ chống lại vi-rút trẻ con hoặc những sai lầm trung thực.
Tất nhiên, đây là một biện pháp chống vi-rút rất khập khiễng và vô dụng, và không có gì ngăn bạn tự thêm dấu chấm vào đường dẫn.
-rftrong thư mục (làm cho rm *thú vị) ;-)
-rfở vị trí đầu tiên? ;)
Đúng. Nếu bạn đặt dấu "." trong đường dẫn, cuối cùng bạn sẽ gửi rất nhiều lệnh gọi đến các tệp trong thư mục hiện tại của bạn.
Ngay cả khi nó là lần cuối, vẫn có lỗi phi công. Ví dụ, Solaris 10 thiếu "đỉnh". Tôi gõ "top" trên hệ thống của mình suốt cả ngày, bởi vì tôi nghĩ rằng tôi đang ở trên một hệ thống có "top".
Xin lỗi, tôi muốn hỏi điều này dưới dạng nhận xét cho câu trả lời đã chọn, nhưng tôi chưa có bất kỳ đại diện nào về siêu người dùng.
Câu trả lời bảo mật có ý nghĩa, nhưng nếu bạn đặt "." trong PATH của bạn là điều cuối cùng, không nên tìm shell trong thư mục hiện tại khi nó tìm kiếm các tệp thực thi, và do đó làm giảm rủi ro bảo mật? Nếu nó đã tìm kiếm $ PATH theo thứ tự, nó sẽ tìm / bin / ls trước khi tìm thấy ./ls.
Vì vậy, làm thế nào không an toàn cho tôi để đặt "." ở cuối biến môi trường $ PATH của tôi?
Nó hoạt động như tôi đề nghị. Đây là cách tôi đã thử nghiệm:
Đầu tiên, thêm "." đến KẾT THÚC của biến môi trường PATH của bạn.
Sau đó, đặt tệp sau vào một số thư mục, chẳng hạn như ~ / dir1 / dir2 / test_which.rb:
#!/your/path/to/ruby
puts "this file is from the current directory"Và đặt tệp này tại /usr/bin/test_which.rb
#!/your/path/to/ruby
puts "this file is at /usr/bin/test_which.rb"Hãy chắc chắn chmod + x các tệp để chúng có thể thực thi được.
Bây giờ, nếu bạn thay đổi thư mục thành ~ / dir1 / dir2 và thực thi test_which.rb, bạn sẽ nhận được đầu ra
this file is at /usr/bin/test_which.rbThật vậy, nếu bạn chạy "which test_which.rb" từ bất cứ đâu, nó sẽ báo cáo
/usr/bin/test_which.rbBạn vẫn có thể thực thi tệp trong thư mục hiện tại bằng cách gõ:
./test_which.rbdchoặc slhoặc sduotrong một vỏ, và đã được cứu bởi "command not found". Không bao giờ.
ls(đầu ra màu và nhiều hơn nữa) được đặt bí danh để lphân phối hoàn toàn với lỗi chính tả.
Hơn một rủi ro bảo mật, có '.' trong PATH làm cho hầu như không thể đảm bảo rằng việc thực thi bất kỳ lệnh nào hoạt động như dự định. Hãy suy nghĩ về việc chạy một lệnh như 'zip' trong thư mục lớn chứa hàng ngàn tệp có tên ngẫu nhiên. Khả năng một trong số chúng thực sự được đặt tên là "zip" là không đáng kể và sẽ dẫn đến một lỗi rất khó hiểu (thực tế, tập tin nên được thực thi, tuy nhiên, điều này có thể xảy ra).
Đặc biệt, điều này đúng khi viết các tập lệnh giữ biến PATH của người dùng. Một kịch bản viết tốt nên xử lý tất cả các trường hợp góc (như tên tệp có khoảng trắng trong đó hoặc bắt đầu bằng '-'). Nhưng việc ngăn chặn một tệp trong thư mục hiện tại được thực thi thay vì lệnh hệ thống là không thực tế ...
lssẽ/usr/bin/lsvà./lskhông. Ngoài ra còn có trở ngại nếu bạn biết cách thêm.vào cuối con đường của mình, bạn có thể có một số ý tưởng về những gì bạn đang làm. root không bao giờ có.trong đường dẫn, nhiều hệ thống thậm chí không cho phép root đăng nhập nữa.