Bash'in kaynağının neden yürütme bitine ihtiyacı yok?

Bash ile sourcebir yürütme bit kümesi olmadan bir betiği çalıştırmak mümkündür. Bu, belgelenmiş ve beklenen bir davranıştır, ancak bu bir yürütme bitinin kullanımına karşı değil mi?

Biliyorum, bu sourcebir deniz kabuğu yaratmıyor.

Bash bir tercümandır; girdiyi kabul eder ve ne isterse yapar. Yürütülebilir biti dikkate alması gerekmez. Aslında, Bash taşınabilirdir ve çalıştırılabilir bir bit kavramına sahip olmayan işletim sistemleri ve dosya sistemlerinde çalışabilir.

Yürütülebilir bit ile ilgilenen, işletim sistemi çekirdeğidir. execÖrneğin, Linux çekirdeği bir dosya gerçekleştirdiğinde, dosya sisteminin bir noexecseçenekle donatılmadığını kontrol eder, program dosyasının çalıştırılabilir bitini denetler ve güvenlik modülleri (SELinux veya AppArmor gibi) tarafından uygulanan gereklilikleri uygular.

Çalıştırılabilir bit'in isteğe bağlı bir denetim türü olduğunu unutmayın. Örneğin, bir Linux x86-64 sisteminde, tercüman olarak açıkça çağırarak/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 çekirdeğin çalıştırılabilir biti doğrulamasını atlayabilirsiniz :

cp /bin/ls /tmp/
chmod -x /tmp/ls
/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 /tmp/ls

Bu, ld.sotercüman olması haricinde, Bash'deki Bash kaynak kodunun kaynaklanmasına biraz benzerdir ve çalıştırdığı kod, ELF biçimindeki makine kodudur.

sourceveya eşdeğeri ancak standart nokta. komut dosyasını çalıştırmaz, ancak komut dosyalarını komut dosyasından okur , sonra bunları geçerli kabuk ortamında satır satır çalıştırır.

Yürütme biti kullanımına karşı hiçbir şey yoktur, çünkü kabuğun sadece dosya içeriğini okumak için okuma iznine ihtiyacı vardır .

Yürütme biti sadece betiği çalıştırdığınızda gereklidir . Burada kabuk fork()yeni bir işlem yapacaktır ve execve()normal, çalıştırılabilir bir dosya olması gereken komut dosyasından yeni bir işlem görüntüsü oluşturmak için işlev kullanacaktır.

Ayarlanamayan ve ayarlanmayan dosyalardaki yürütülebilir bit (diğerlerinden farklı olarak) bir güvenlik mekanizması değildir. Okuyabildiğiniz her şeyi dolaylı olarak çalıştırabilirsiniz ve Linux doğrudan çalıştırabileceğiniz ancak doğrudan okuyamayacağınız bir şeyi dolaylı olarak okumanıza izin verecektir (bu, setsiz (g) kullanıcı kimliği olmayan x-bit kavramına bir delik açmak için yeterli olmalıdır. güvenlik önlemi).

Bu çok daha kolay bir şey: Bit ayarlanmışsa sistemin doğrudan benim için çalıştırmasına izin verin, aksi halde dolaylı olarak yapmam gerekir ( bash the_script;veya okunamaz durumda olan bir uygulamanın hafıza görüntüsünü elde etmek için bilgisayar korsanlığı ).

Hem kaynağında hem de kaynağınızda yürütmeyi düşünüyorsanız, kolaylık sağlamak için ayarlayabilirsiniz.

Bununla birlikte, görünüşe göre, birçok paylaşılan kütüphane uygulayıcısı düşüncenizi paylaşır ve sonuç olarak, birçok sistem, esas olarak kabuk kaynak kaynaklarının yerel eşdeğeri olan paylaşılan kitaplıkların kullanılabilir olması için çalıştırılabilir olarak işaretlenmesini gerektirir. Bkz Neden paylaşılır kütüphaneler yürütülebilir? .

Bu iyi bir soru! Unix, programları ve verileri birbirinden ayırmak için yürütülebilir biti kullanır. İşletim sistemi yürütme biti gerektirmez, çünkü kaynak kodlu bir komut dosyası işletim sistemine yeni bir işlem olarak geçmediği için işletim sistemi tarafından geçilmez. Ancak kabuk, kaynak kodlu bir betiği bir program olarak ele alır ve kaynaklamak $PATHistediğiniz dosyayı arar . Dolayısıyla, kabuğun kendisi kaynak dosyalar için yürütme izni gerektirebilirdi; ama olmadı.

Soru uzun zaman önce ortaya çıkmış olmalı. Bourne kabuğunun tasarımı, Bell Laboratuarlarının sakinleri arasında "uzun bir değişiklik dizisi, diyalog, tartışma" nın sonucuydu ve birçok tasarım kararı SR Bourne ve diğerleri tarafından yıllar boyunca tartışıldı. Maalesef, hızlı bakışım kaynak özelliği hakkında herhangi bir tartışma bulamadı (savunmamda, bunun için google yapmak zor). Bulduğum şey "." Bourne'un kendisi tarafından kabuğa bu ilk girişte komut görünmüyor , ancak daha olgun olan Versiyon 7 versiyonunda mevcut .

Yok otorite, işte kendi yorumum:

1. .Komut, diğer adıyla source, (gibi etki metinsel dahil olduğu #includeyürütme komut dosyası veya etkileşimli oturumda kaynak koduna C önişlemcisine olarak). Bu nedenle, dahil edilen dosyanın tartışmasız "çalıştırılmadığı".

2. Unix felsefesi daima programcılara kendilerini asacak kadar ip vermek olmuştur. Çok fazla el tutma ve keyfi kısıtlama yolunda gitmektedir. Sadece son zamanlarda bazı dağıtımlar rm -r /ne istersen yapmayı reddetti. (Bu komut söyler rmetmek . Bilgisayarınızdaki her şeyi silmek root olarak deneyin! Etmeyin ark, belki Bourne'u. Hiç de daha iyisi Ya) Yani. Sadece bir dosyayı bulmaya çalıştığınızda ne yaptığınızı bildiğiniz varsayılır. Bu da gereksiz işleri önler ve döngüleri o zamanlar çok önemlidir.

İşletim sistemi söz konusu olduğunda, kabuk betiğini içeren bir dosya sadece veridir. Bu tür bir veri dosyasının adını sourcekomuta veya komut satırından bash kabuğunun çağrılmasına geçirirseniz, tüm işletim sistemi görür, veri içeren bir dosyanın adıyla çakışan bir dizedir.

Bu durumda yürütme biti nasıl bir anlam ifade eder?

Bu ayrım önemlidir, çünkü çalıştırılabilir olarak kullanışlı olmayan, ancak yalnızca kaynak yapıldığında yararlı olan bir kabuk komut dosyanız olabilir. Bu dosya için çalıştırma bitini kapatabilirsiniz ve daha sonra bir kaynak komutunda açıkça belirtilmedikçe asla erişilmez. Böyle bir şeyin nedeni, çalıştırıldığı kabuk üzerinde yan etkilere neden olmaktır. Belirli bir örnek için, fix_path adında ve yolu değiştiren bir komut dosyası var.

Birisinin daha fazla araştırma ve / veya açıklama ile ilgilenmesi durumunda: Bir süre önce uygulanan 'exec_program ()' ve 'builtin_source ()' işlevlerinin içsel çalışmaları çok örnek niteliğindedir. Bu işlevlerde, aralarındaki farkın tam olarak ne olduğunu görüyorsunuz:

https://github.com/rsenn/shish/blob/master/src/builtin/builtin_source.c

https://github.com/rsenn/shish/blob/master/src/exec/exec_program.c

Temel olarak kaynak, kabuk komut dosyasını ayrıştırdığı iç dosya tanımlayıcısını geçici olarak yönlendiren kabuk (etkileşimli modda terminal) olarak görülebilir. bu nedenle gibi diğer yönlendirmeler çok benzer <input_file.txtve >>append_to_something.listbunlar sadece açmak ve kapatmak dosyalar gerekir ve.

bu nedenle yürütme, execve()yürütme bitinin zorunlu olduğu sistem çağrısı tarafından gerçekleştirilir.

ELF / a.out ikili dosyalarının yürütülmesine izin veren bazı sistemleri gördüğümü hatırlıyorum, ancak "/lib/ld-dynamic-linker.so" ve ikili programla (exec bit olmadan) ilk argüman olarak çalıştırarak. Bunun bazı DEC Alpha veya VAX makinelerinde olduğuna inanıyorum (SCO Unix olabilir mi?)

Başka bir bakış açısı:

Kaynak komut dosyası temelde kabuk yerleşimleri ve program çağrılarından oluşur. Kabuk sourceyapıları ( bunlarla birlikte) kabuğun parçalarıdır ve kabuğun ilk önce çalıştırılabilir olması gerekir. Her program (ELF olan, shebang ile başka bir betik, her neyse) olarak adlandırılan yürütme biti ayarlanmış olmalıdır, aksi takdirde çalışmayacaktır.

Bu nedenle, yürütme biti kullanımına karşı değildir, çünkü yürütme biti olmayan hiçbir şey çalışmaz. Doğrulama, kaynak kodun tamamı için yapılmaz; Her bölüm için ayrı ayrı yapılır, ancak öyle.