共有ライブラリを実行可能にする必要があるのはなぜですか（Red HatとDebianなど）？
これは、「 。soファイルが実行可能である理由 」とほぼ重複していますが、完全には重複していません。
Red Hatベースのシステムでは、共有ライブラリには実行権限がありますが、Debianではありません。
論理的にシャードされたライブラリは、（巧妙なリンクを介して）設計されていない限り、それ自体では実行できません。ただし、それらに含まれるコードは実行されます。つまり、少し灰色の領域です。
面白いアーティックがあります
リンクされた質問は、歴史的な理由から、またHP-UXのような一部のUnixライクなOSの要件であることを示唆しています。
ここでDebianとRedHatがもう少し深く異なる理由を理解したいと思います。
どのシステムが変更され、その理由は何ですか？
BSDの状況はどうですか？
考えられるセキュリティ上の考慮事項はありますか？
更新：2017年10月26日
Red Hatがこの件について言わなければならなかったことは次のとおりです（私の強調）：
ライブラリに実行可能ビットを設定しても、シェルから実行できる以外の効果はありません。 Linuxの共有ライブラリは、ELFと呼ばれる形式です。これはExecutable and LinkableFormatの略です。これは、実行可能ファイルと共有ライブラリの両方の形式であるため、ライブラリが実行可能ビットでマークされているのはそのためです。 GCCは、デフォルトで実行可能ビットが設定された共有ライブラリを作成することに注意してください。
ダイナミックローダーはライブラリの権限を気にしないため、実行可能ビットを削除しても副作用はありません（libcなどの特定のライブラリを実行して情報を表示できないことを除く）。代わりに、ライブラリの一部をマップしますメモリの一部に、実行が必要な部分は、以前にPROT_EXECとしてマークされたメモリ領域にマップされます。
したがって、指摘されているように、ライブラリが実行不可能としてインストールされているのはDebianポリシーです。プラットフォームに依存しないgcc（またはむしろld）は、ライブラリをデフォルトで実行可能にすることで、注意を怠ると思いますか？
ここに興味深い記事があります： https://www.technovelty.org/linux/shared-libraries-and-execute-permissions.html
参照 https://stackoverflow.com/questions/6299395/gcc-generates-shared-object-with-execute-permissions
Debianはこれを1997年にポリシーバージョン2.2で変更しました（ ＃7129 を参照してください。ただし、詳細はまったく説明されておらず、他の議論は見つかりませんでした）。理由が示されています したがって、現在のバージョンのポリシーでは ：
ダイナミックリンカはこれを必要とせず、共有ライブラリを実行しようとすると通常コアダンプが発生するため、共有ライブラリは実行可能ファイルとしてインストールしないでください。
つまり、それは本当に期待を管理することであり、驚き最小の原則です。実行が役に立たない場合は、実行可能ファイルとしてマークしないでください。 Debianとその派生物では、実行可能であると想定されるライブラリは、実行時に何か意味のあることを行うライブラリ（Cライブラリ、libpthread、そしてもちろんダイナミックリンカなど）だけです。
FreeBSDとOpenBSDでは、少なくとも、オペレーティングシステムの共有ライブラリは実行可能ではありません。 OpenBSDでは、これは一般的に/usr/localの共有ライブラリにも当てはまります。 FreeBSDでは、ポートやパッケージからの/usr/localの共有ライブラリが実行可能であることがよくあります。 （ BSD関連の情報 を提供してくれた JdeBP に感謝します。）
Linuxでは、ライブラリを実行するために実行可能ビットを設定する必要がないため（少なくとも、基本的なLinuxシステムでは）、セキュリティに関する特別な考慮事項はないと思います（動的リンカーを使用して実行できます）。 。