Bashのソースに実行ビットが必要ないのはなぜですか？

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

sourceサブシェルは作成されません。

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

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

sourceまたは同等の標準ドット.はスクリプトを実行しませんが、スクリプトファイルからコマンドを読み取り、現在のシェル環境で1行ずつ実行します。

シェルはファイルの内容を読み取るための読み取り許可のみを必要とするため、実行ビットの使用に反対するものはありません。

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

nonsetuidおよびnonsetguidファイルの実行可能ビット（残りとは異なります）は、セキュリティメカニズムではありません。読むことができるもの、間接的に実行することができ、Linuxでは、実行できるが直接読むことができないものはすべて間接的に読み取ることができます（non-set（g）uid x-bitの概念に穴を開けるのに十分なはずです）セキュリティ対策）。

それはもっと便利なことです：ビットが設定されている場合、システムに直接実行させてください。そうでない場合は、間接的に行う必要があります（bash the_script;または読み取り禁止の実行可能ファイルのメモリイメージを取得するためのハッキングが必要です）。

インソースとインソース可能の両方を実行する場合は、便利に設定できます。

しかし、どうやら、多くの共有ライブラリの実装者があなたの考えを共有しているため、多くのシステムでは、本質的にシェルのインソース不可能なネイティブライブラリである共有ライブラリを使用可能にするために実行可能にする必要があります。共有ライブラリが実行可能な理由をご覧ください。。

それは良い質問です！Unixは実行可能ビットを使用して、プログラムとデータを区別します。新しいプロセスとして実行するためにソーススクリプトがOSに渡されないため、OSは実行ビットを必要としません。ただし、シェルはソーススクリプトをプログラムとして扱い、ソース$PATHするファイルを探します。そのため、シェル自体がソースファイルの実行権限を必要としている可能性があります。しかし、そうではなかった。

質問はずっと前に出されたに違いありません。Bourneシェルの設計は、Bell Labsの住人の間で行われた「修正、対話、議論の長いシーケンス」の結果であり、多くの設計決定がSR Bourneと他の人によって長年にわたって議論されました。残念なことに、私のクイックルックでは、ソース機能に関する議論は見つかりませんでした（私の防御では、Googleで検索するのは難しいです）。私が見つけたのは、「。」コマンドは、Bourne自身によるこのシェルの初期の紹介には登場しませんが、より成熟したバージョン7バージョンには存在します。

権限がない場合、ここに私自身の解釈があります：

1. .コマンドは、別名source、（のような効果テキスト包含している#include実行スクリプトまたは対話型セッションのソースコードにCプリプロセッサで）。そのため、含まれているファイルは、おそらく「実行」されていません。

2. Unixの哲学は常に、プログラマーに自分自身を掛けるのに十分なロープを与えることでした。あまりにも多くの手持ちと任意の制限が邪魔になります。ごく最近になって、いくつかのディストリビューションrm -r /が、あなたが求めていることを拒否したようになりました。（このコマンドは、コンピューター上のすべてrmを削除する ように指示します。root として試してはいけません！または、さらに良いことに、まったくありません。）ファイルを入手しようとすると、自分が何をしているのかを知っていると仮定するだけです。それはまた、不必要な作業を回避し、当時はサイクルが非常に重要でした。

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

その場合、実行ビットはどのように関連しますか？

実行可能ファイルとしては役に立たないが、入手した場合にのみ役立つシェルコマンドのファイルがある場合があるため、この区別は重要です。このファイルの場合、実行ビットをオフにすると、ソースコマンドで明示的に指定されない限りアクセスされなくなります。このようなことの理由は、実行元のシェルに副作用があるためです。具体的な例として、パスを調べて変更するfix_pathというスクリプトがあります。

誰かがさらなる研究や説明に興味がある場合に備えて：少し前に実装されたほぼPOSIX準拠のシェルでは、 'exec_program（）'および 'builtin_source（）'関数の内部動作は非常に模範的です。これらの関数では、それらの違いが正確にわかります。

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

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

基本的に、ソースは、シェルが内部ファイル記述子を一時的にリダイレクトし、そこからシェルスクリプトを解析する（対話モードの端末）ように見えます。ですから、<input_file.txtや>>append_to_something.listなどの他のリダイレクトと非常によく似ており、これらはファイルを開いたり閉じたりするだけです。

そのため、実行はexecve()、実行ビットが必須のシステムコールによって処理されます。

ELF / a.outバイナリの実行を許可するいくつかのシステムを見たことを思い出しますが、「/ lib / ld-dynamic-linker.so」を実行し、最初の引数としてバイナリプログラム（execビットなし）を使用します。私はそれがいくつかのDEC AlphaまたはVAXマシンにあったと信じています（SCO Unixだったのでしょうか？）

別の観点：

ソーススクリプトは、基本的にシェルの組み込みとプログラム呼び出しで構成されます。シェルのビルトイン（sourceその中にある）はシェルの一部であり、シェルは最初に実行可能でなければなりません。呼び出されるすべてのプログラム（ELF、シバンを含む別のスクリプトなど）には実行ビットを設定する必要があります。そうしないと実行されません。

実行ビットがないと実行されないため、実行ビットの使用に反しません。検証は、ソーススクリプト全体では発生しません。パーツごとに個別に実行されますが、実行されます。