仮定setuid/setgidビットは重要ではありません。別の実行権限が必要なのはなぜですか？
哲学的には、書き込み権限には読み取り権限が含まれ、読み取り権限には実行権限が含まれていると思います。もちろん、Linuxではそうではありません。時には便利ですが、私の考えにはほとんどありません。たとえば、プロセスが実行できないファイルを読み取ることができる場合は、プロセスがディレクトリに書き込める限り、単にファイルをディレクトリにコピーして実行ビットを設定してからプログラムを実行できます。実際には、読み取りには単純なケースの実行が含まれます。明らかに、これはソースファイルにsetuidビットがある場合、またはプロセスがnoexecマウントポイントにのみ書き込むことができる場合は正しく機能しません。
私がこの質問をするのは、プロセスがexec任意のメモリブロックにアクセスできるようにするLinuxシステムコールを実装しているからです。 （具体的なユースケースは、メインプログラムに完全なプログラムがバンドルされており、呼び出すためにディスクに書きたくないということです。execve）このようなシステムコールに深刻な問題がありますか？認識？
ベストアンサー1
推測できるように、実行権限は権限ほど有用ではありません。ファイルの属性ではなく権限で持つことは、いくつかの歴史的思考です。しかし、一度存在すると消えません。どちらの場合も、読み取り権限とは異なる実行権限を持つことが重要です。
- ファイルを実行すると、追加の権限が付与されている場合は、その特定のファイルを実行できる人が重要です。 setuid、setgid、またはsetcapの実行可能ファイルは誰でも読むことができますが、誰でも実行することはできません（多くのディストリビューションではsetxidファイルが機密ではないため、誰でも読むことができます。誰でもディストリビューションからファイルをダウンロードできます）。
- 一部のアカウントは制限されており、実行可能ファイルに何も書き込めません。たとえば、アカウントには次のアクセス権しかありません。限られた殻なし
chmodまたはを使用してマウントされたファイルシステムのディレクトリにのみ書き込むことができますnoexec。これらのユーザーは既存の実行可能ファイルのみを使用できます。
メモリからexecにシステムコールを追加すると、制限されたアカウントが任意のコードを実行できるようになります。これは、限られたアカウントを含むどこからでもアクセスできる基本的なコードソルバーを持つのと同じです。これはセキュリティ制限に違反するため、主流のカーネルでは許可されません。自分のコンピュータに展開できますが、その意味を念頭に置いてください。
しかし、すでに存在する機能には多くの作業とセキュリティ手荷物が必要です。ディスクに書き込むことなくコードを実行できます。ディスクではなくファイルシステム（tmpfsなど）のファイルにコードを書くだけです。