重複の可能性:
共有ライブラリが実行可能なのはなぜですか?
Linuxで.so
ファイル権限が/lib
644ではなく755の理由は何ですか?これは奇妙です
~によるとhttp://www.gossamer-threads.com/lists/gentoo/user/231943、これは古いglibcのようです。私の組み込みシステム/lib/libc.so.6では、権限644でも動作します。
答え1
私はこれが歴史的な理由だけだと思います。
BlueBomberの答えは歴史的に正しいかもしれませんが、実際にはそうではありません。必要共有オブジェクトを実行可能にします。
私のUbuntuシステムではそうではありません。 30個と/lib/*.so*
600個のファイルのうち/usr/lib/*.so*
1つだけが実行権限を持っています。これはおそらく単純な欠陥です。
実行権限を使用すると、ファイルをその機能のいずれかで実行できますexec*()
。共有オブジェクトファイルには実行可能なコードが含まれていますが、そのようには実行されません。
一方、私がアクセスできるCentOS 5.7システムでは、このファイルははい実行可能ファイル。 SPARC Solaris 9システムにもあります。 (これらのファイルの一部の実行権限をオフにして問題があるかどうかを確認するのは面白いかもしれませんが、そうすることはできません。)
(どのLinuxディストリビューションを使用していますか?)
修正する:
この回答到着この問題実際に実行ビットが必要なシステム(HP-UX)の例を示します。一部のディストリビューションには実行ビットセット(おそらく歴史的慣性のため)があり、他のディストリビューションではそうでないLinuxではそうではありません。あるいは、いくつかのLinuxではこれを要求するかもしれません。
別のデータポイント:私のUbuntuシステムで独自の共有オブジェクトファイルを作成しました。結果の "libfoo.so"ファイルは実行権限で生成されますが、手動で実行するとchmod -x
それを使用するプログラムは引き続き機能します。
それにもかかわらず、*.so
ファイルの実行権限を設定することは基本的に無害です(そして確かにソースファイルの実行権限を設定するよりも面倒です)。
アップデート2:
fwyzardがコメントで指摘したように、いくつかの*.so
ファイルは実際には実行可能です。たとえば、現在のシステムでこのコマンドを実行すると、/lib/x86_64-linux-gnu/libc-2.27.so
GNU Cライブラリのバージョン情報が印刷されます。 /lib/x86_64-linux-gnu/libpthread-2.27.so
行動も似ています。
答え2
あなたの質問を理解したら、共有オブジェクトファイルに実行権限がある理由を尋ねることです。これはリンクするライブラリファイルであり、埋め込みコードが実行されるためです。
引用: