☰

Bash のソースにはなぜ実行ビットが必要ないのでしょうか?

tag-icon • tag-icon bash permissions executable source conventions
Bash のソースにはなぜ実行ビットが必要ないのでしょうか?

Bash では、source実行ビットを設定せずにスクリプトを実行することができます。これは文書化されており、想定される動作ですが、実行ビットの使用に違反しているのではないでしょうか。

わかっています、それではsourceサブシェルは作成されません。

答え1

sourceまたは同等だが標準的なドット.スクリプトを実行せず、読むスクリプト ファイルからコマンドを取得し、現在のシェル環境で行ごとに実行します。

実行ビットの使用に反対する理由はない。シェルは読むファイルの内容を読み取る権限。

実行ビットは、次の場合にのみ必要です。走るスクリプト。ここでシェルはfork()新しいプロセスを作成し、execve()スクリプトから新しいプロセス イメージを作成する機能。このプロセス イメージは通常の実行可能ファイルである必要があります。

答え2

Bash はインタープリタです。入力を受け入れて、やりたいことを実行します。実行ビットを考慮する必要はありません。実際、Bash は移植性があり、実行ビットの概念を持たないオペレーティング システムやファイル システムでも実行できます。

exec実行ビットを気にするのは、オペレーティング システム カーネルです。たとえば、Linux カーネルが を実行する場合、ファイルシステムnoexecがオプションでマウントされていないことを確認し、プログラム ファイルの実行ビットをチェックし、セキュリティ モジュール (SELinux や AppArmor など) によって課せられた要件を適用します。

実行ビットは、かなり裁量的な制御であることに注意してください。たとえば、Linux x86-64システムでは、カーネルによる実行ビットの検証をバイパスすることができます。/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2インタープリタとして明示的に呼び出す:

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

これは、Bash で Bash ソース コードを取得することに多少似ていますが、Bash はld.soインタープリターであり、実行されるコードは ELF 形式のマシン コードである点が異なります。

答え3

非 setuid ファイルおよび非 setguid ファイルの実行可能ビット (他のビットとは異なり) は、セキュリティ メカニズムとしてはあまり役に立ちません。読み取り可能なものはすべて間接的に実行でき、Linux では、実行可能だが直接読み取りできないものはすべて間接的に読み取りできます (これは、非 set(g)uid x ビットがセキュリティ対策であるという概念に穴を開けるのに十分なはずです)。

これは利便性の問題です。ビットがセットされている場合はシステムが直接実行し、そうでない場合は間接的に（bash the_script;または何らかの方法で）実行する必要があります。読み取り権限のない実行ファイルのメモリイメージを取得するためのハッキング）。

インソースとインソース可能な実行の両方を行う場合は、便宜上これを設定することができます。

しかし、どうやら多くの共有ライブラリ実装者はあなたの考えを共有しており、その結果、多くのシステムでは、シェルインソースのネイティブ同等物である共有ライブラリが使用可能になるために実行可能としてマークされることが求められています。共有ライブラリが実行可能であるのはなぜですか?。

答え4

OS に関する限り、シェル スクリプトを含むファイルは単なるデータです。このようなデータ ファイルの名前をコマンドに渡したりsource、コマンド ラインで bash シェルの呼び出しに渡したりしても、OS が認識するのは、データを含むファイルの名前と偶然一致する文字列だけです。

その場合、実行ビットはどのように関係するのでしょうか?

関連情報