Yıllar boyunca UNIX benzeri sistemlerde (en çok benim için, Linux), .(geçerli dizinin) hiçbir zaman $PATHvarsayılanda olmadığını fark ettim . Bu neden?
Yıllar önce bir güvenlik sorunu olduğunu okudum, ancak okuduğum makalede sorunun tam olarak ne olduğunu açıklamadım. Birinin kötü niyetli bir sürümünü lsveya cpbir dizinde bırakabileceği ve orada olduğunu fark etmeden çalıştırabileceğim için mi?
Yanıtlar:
Kendi sorunuzu doğru cevapladınız, nokta tam da bu yüzden yolun üzerinde
durmuyor : Çocukça virüslere veya dürüst hatalara karşı korunma.
Tabii ki, bu çok topal ve işe yaramaz bir antivirüs önlemidir ve hiçbir şey sizi yola nokta eklemekten alıkoyamaz.
-rfdizindeki tek bir dosyadan değilsin ( rm *ilginç yapıyor) ;-)
-rfilk başta isimlendirdiniz ? ;)
Üzgünüz, bunu seçilen cevaba bir yorum şeklinde sormak isterim, fakat henüz süper kullanıcı ile ilgili bir sorum yok.
Güvenlik cevabı anlamlı, fakat "." Koyarsanız PATH'nizdeki son şey olarak, kabuğun yürütülebilir dosyaları ararken en son geçerli dizine bakmaması ve böylece güvenlik riskini azaltmaması gerekir mi? Sırasıyla $ PATH araması yapsa, / bin / ls dosyasını bulur.
Peki benim için "." Koymak ne kadar güvensiz? $ PATH ortam değişkenimin sonunda?
Önerdiğim gibi çalışıyor. İşte nasıl test ettik:
İlk önce, "" ekleyin. PATH ortam değişkeninizin END'sine
Ardından, aşağıdaki dosyayı ~ / dir1 / dir2 / test_which.rb gibi bir dizine yerleştirin:
#!/your/path/to/ruby
puts "this file is from the current directory"Ve bu dosyayı /usr/bin/test_which.rb dosyasına koyun.
#!/your/path/to/ruby
puts "this file is at /usr/bin/test_which.rb"Dosyaları çalıştırılabilir olması için chmod + x olduğundan emin olun.
Şimdi, dizini ~ / dir1 / dir2 olarak değiştirirseniz ve test_which.rb komutunu çalıştırırsanız, çıktıyı alırsınız.
this file is at /usr/bin/test_which.rbGerçekten de, "hangi test_which.rb" yi bir yerden çalıştırırsanız, rapor vermesi gerekir.
/usr/bin/test_which.rbDosyayı geçerli dizinde hala yazarak çalıştırabilirsiniz:
./test_which.rbdcya slya sduobir kabuk içinde ve "komutu bulunamadı" tarafından kurtarıldı. Hiç.
lsdiğer adı (renk çıktısı ve daha fazla) lyazım hatası tamamen dağıtmaktadır.
Güvenlik riskinden daha fazlası, '' PATH'de, herhangi bir komutun yürütülmesinin amaçlandığı şekilde davrandığından emin olmak neredeyse imkansızdır. Binlerce dosya içeren rastgele isimlerden oluşan büyük dizinde 'zip' gibi bir komut çalıştırmayı düşünün. Bunlardan birinin aslında 'zip' olarak adlandırılma olasılığı ihmal edilemez ve anlaşılması çok zor olan bir hataya yol açacaktır (aslında dosya olabilir, ancak çalıştırılabilir olmalıdır).
Özellikle, kullanıcının PATH değişkenini tutan komut dosyaları yazarken bu doğrudur. İyi yazılmış bir senaryo bütün köşe davalarıyla (boşlukları olan veya '-' ile başlayan dosya adları gibi) ele alınmalıdır. Ancak geçerli dizindeki bir dosyanın sistem komutu yerine çalıştırılmasını engellemek pratik değildir ...
lsolacak/usr/bin/lsve olmayacak rasgele bir dizinde olduklarını bilmek gibi./ls. Ayrıca,.yolunuzun sonuna nasıl ekleneceğini biliyorsanız , muhtemelen ne yaptığınız hakkında bir fikriniz vardır. Kök gerektiğini asla sahip.yolunda birçok sistemler bile artık kök günlüğünü izin vermeyin.