これは私がそれを使用している間に気付いた機能を扱っているので、重複していません/etc/ld.so.conf。
動的リンカーがライブラリを検索するパスを取得するには、コマンドを実行しますldconfig -v | grep -v "^"$'\t' | sed "s/:$//g"。/etc/ld.so.confそこにパスがリストされていない場合 。前のコマンドの出力は次のとおりです。
/lib
/usr/lib
/libまず検索してから検索するようです/usr/lib。新しいパスを追加すると（たとえば、/usr/local/libto/etc/ld.so.confとremake）、/etc/ld.so.cache出力はldconfig -v | grep -v "^"$'\t' | sed "s/:$//g"次のようになります。
/usr/local/lib
/lib
/usr/lib
リストされているディレクトリの検索順序が上から下に正しく想定されると、他のディレクトリが以前に検索される/libため、これは奇妙だと思います/usr/lib。信頼できるディレクトリ以前に他のディレクトリを検索すること自体は奇妙なことではありませんが、以前に/lib検索するときは＆内で＆を検索する/usr/libので奇妙です。/bin/sbin/usr/bin/usr/sbinPATH
ldconfig -v | grep -Ev "^"$'\t' | sed "s/:$//g"リストされているパスを下から上に検索しても、他のディレクトリは信頼できるディレクトリの後で/libはなく、信頼できるディレクトリの後に検索されるため、まだ順序が歪んでいます/usr/lib。
ld.soそれでは、ライブラリパスが検索される順序は何ですか？/lib以前に検索された理由は何ですか/usr/lib？そうでなければ、後で別のディレクトリを検索したいのはなぜですか/lib？
ベストアンサー1
このシーケンスは動的リンカーのマニュアルに文書化されています。ld.so。これは：
LD_LIBRARY_PATHの目次/etc/ld.so.confの目次/lib;/usr/lib。
（少し簡素化しました。詳しくはマニュアルをご覧ください。）
この順序は、これがデフォルトの場所のライブラリをカスタムライブラリにオーバーライドする唯一の方法であると考えるときに意味があります。LD_LIBRARY_PATH他の設定よりも優先する必要があるユーザー設定です。/etc/ld.so.confオペレーティングシステムのデフォルトより前のローカル設定。したがって、ユーザーとして別のバージョンのライブラリを使用してプログラムを実行したい場合は、LD_LIBRARY_PATH他のバージョンのライブラリを含む場所でプログラムを実行できます。管理者として、私はさまざまなバージョンのライブラリを配置して一覧/usr/local/lib表示/usr/local/libできます/etc/ld.so.conf。
信頼はこれとは何の関係もありません。この検索パスにリストされているすべてのディレクトリは最終的にそのディレクトリから読み込まれる可能性があるため、信頼できる必要があります。理論的には、「より信頼性の高い」システム内のすべてのプログラムで使用されるライブラリ名を一覧表示し、すべてのライブラリが「最も信頼できる」ディレクトリにあることを確認してから、「信頼性の低い」ディレクトリは表示されません。検索パスでより信頼できるディレクトリの背後にある場合は、「信頼性が低い」プログラムを除いて使用できます。しかし、それは非常に脆弱です。これも意味がありません。攻撃者が値LD_LIBRARY_PATHや要素を注入できる場合は、ofなどの値を/etc/ld.so.conf注入するなど、任意のコードを実行するより直接的なパスが必要です。ライブラリのロードパス信頼は、実行が信頼境界を超えたとき、つまり追加の権限を持つプログラム（setuid / setgidプログラムなど）を実行するときに重要です。この場合に起こるのは、それが空になるということです。PATHLD_PRELOADsudoLD_LIBRARY_PATH
/libvs の場合には/usr/lib重要ではありません。同じエンティティ（オペレーティングシステム）によって提供され、両方にライブラリがあってはいけません。/lib（非常にわずかな）パフォーマンス上の利点を提供するので、最初にリストするのが合理的です。最も一般的に使用されるライブラリ、特に小さな基本プログラム（ロード時間が大規模長期実行プログラムよりも総実行時間の割合が高い）に使用されます。使用されているライブラリはにあります/lib。