rpath

コンピューティングにおいて、rpath は実行可能ファイルまたはライブラリにハードコードされた実行時 検索パスを指定します。動的リンクローダーはrpath を使用して必要なライブラリを検索します。

具体的には、共有ライブラリへのパスを実行可能ファイル (または別の共有ライブラリ) のヘッダーにエンコードします。この RPATH ヘッダー値 (実行可能ファイルおよびリンク可能形式のヘッダー標準でこのように命名されています) は、システムのデフォルトの動的リンク検索パスを上書きまたは補足する場合があります。

実行可能ファイルまたは共有ライブラリの rpath は、ELF.dynamic実行可能ファイルまたは共有ライブラリの セクション内のオプションのエントリで、 属性と呼ばれるタイプを持ちます。これは、リンカーによってリンク時にそこに保存できます。 や などのツールは、後でエントリを作成または変更できます。 DT_RPATHDT_RPATHchrpathpatchelf

ELF のさまざまなダイナミック リンカーは、属性の使用をDT_RPATHさまざまな方法で実装します。

GNU Cライブラリのダイナミックリンカーは、以下の順序で共有ライブラリを検索します。^[1]

1. DT_RPATHバイナリの動的セクション属性内のパス（コロンで区切られた）（存在する場合）およびDT_RUNPATH属性が存在しない場合。
2. LD_LIBRARY_PATH実行ファイルがバイナリでない限り、環境変数 内の (コロンで区切られた) パスはsetuid/setgid無視されます。LD_LIBRARY_PATHオプション--library-path(例/lib/ld-linux.so.2 --library-path $HOME/mylibs myprogram) を使用して動的リンカーを呼び出すことで上書きできます。
3. DT_RUNPATHバイナリの動的セクション属性内の（コロンで区切られた）パス（存在する場合）。
4. ldconfigキャッシュ ファイル (多くの場合 にあります)に基づいて検索します。/etc/ld.so.cacheこのファイルには、拡張ライブラリ パス ( によって設定) で以前に見つかった候補ライブラリのコンパイル済みリストが含まれています/etc/ld.so.conf。ただし、バイナリが-z nodefaultlibリンカー オプションでリンクされている場合は、デフォルトのライブラリ パスにあるライブラリはスキップされます。
5. 信頼されたデフォルト パスで/lib、 を実行します/usr/lib。バイナリが-z nodefaultlibリンカー オプションを使用してリンクされている場合、この手順はスキップされます。

これらすべての場所で共有ライブラリが見つからない場合は、「共有オブジェクト ファイルを開けません: そのようなファイルまたはディレクトリはありません」というエラーが発生します。

注:

• readelf -d <binary_name> | grep 'R.*PATH'バイナリ ファイルの RPATH または RUNPATH を表示します。たとえば、gcc-Wl,-rpath,/custom/rpath/では、 によって RPATH を指定できます。
• --inhibit-rpath LISTダイナミック リンカーのオプションは、LIST 内のオブジェクト名の属性を無視するように指示します。LIST 内のメイン プログラムを指定するには、空の文字列を指定しますDT_RPATH。DT_RUNPATH
• 環境変数で指定されたライブラリLD_PRELOADと、次に にリストされているライブラリは/etc/ld.so.preload、検索が開始される前にロードされます。したがって、プリロードは、要求されたライブラリの通常の機能の一部 (またはすべて) を置き換えるために使用することも、そうでなければ見つからないライブラリを提供するために使用することもできます。
• 静的ライブラリはリンク時に検索され、ELF ファイルにリンクされますが、実行時には検索されません。

GNUリンカー（GNU ld）は、「new-dtags」と呼ばれる機能を実装しており、これを使用してLD_LIBRARY_PATH 環境変数よりも優先順位の低いrpathを挿入することができます。 ^[2]

リンカー ( --enable-new-dtags) で new-dtags 機能が有効になっている場合、GNU は属性をld設定するだけでなく、属性を同じ文字列にDT_RPATH設定します。実行時に、動的リンカーが属性を見つけると、属性の値を無視します。その結果、最初に属性がチェックされ、属性内のパスは後でのみ検索されます。 DT_RUNPATHDT_RUNPATHDT_RPATHLD_LIBRARY_PATHDT_RUNPATH

ldダイナミックリンカーはDT_RUNPATHとは異なり、推移的な依存関係の場所を検索しませんDT_RPATH。^[3]

-rpathリンカーに を指定する代わりに、環境変数をLD_RUN_PATH設定して同じ効果を得ることもできます。

Solaris、特にSunOS/lib/ld.so 5.8 および類似システムの動的リンカーは、属性を見る前に LD_LIBRARY_PATH 変数で指定されたディレクトリでライブラリを探します。Sun Microsystems は、動的ライブラリの読み込みを最初に導入した企業です^[要出典]。Sun は後に ld に rpath オプションを追加し、セキュリティ機能強化のために必須ライブラリで使用しました。GNU ld も同様に Sun スタイルの動的ライブラリをサポートしました。 DT_RPATH

$ cc  -shared  -Wl、-soname、termcap.so.4、-rpath、/lib/termcap.so.4  -o  termcap.so.4

$ objdump  -x  termcap.so.4
  必要 libc.so.6 
  SONAME termcap.so.4 
  RPATH /lib/termcap.so.4

この例では、GNU または Sun ld (ld.so) は、ファイルがにあり、 という名前termcap.soでない限り、termcap を必要とするプログラムが termcap をロードすることを拒否します。LD_LIBRARY_PATHは無視されます。が修正のために削除されると、シェルは終了します (代替をロードできず、レスキュー ディスクが必要になりますが、新しい にRPATH /lib がある場合、 が上書きされない限り、ld.so は を使用したロードを拒否します)。しかし、別の問題があります。 のライブラリの一部は「使用中」であるため、コピーするのは安全ではなく、ライブラリ テスターに​​なる予定のユーザーをさらに制限します。さらに、/lib/termcap.so.4/lib/termcap.so.4termcap.sotermcap.so.4/lib/termcap.so.4/libSONAME termcap.so.4対。SONAME termcap.sotermcap.so上記のライブラリが基本サポートへの ABI アクセスを削除したため、 基本を必要とするプログラムが拒否されることを意味します。

$ cc  -shared  -Wl,-soname,libtermcap.so.2  -o  libtermcap.so.2

$ objdump  -x  termcap.so.2
  必要 libc.so.6 
  SONAME termcap.so.2

古い Linux/Sun では上記が使用されており、ユーザーはLD_LIBRARY_PATHtermcap.soで指定したもの、または などの検索ルールを使用して /usr/local/lib(n) で見つかったものを使用するように任意のプログラムに指示できます。ただし、GNU ld はLD_LIBRARY_PATH の前にまたは を常に使用するため、最初に がに移動され、で言及されている が に移動され、 を に移動してまたはLD_LIBRARY_PATHをに使用できるようになります。推奨される方法は、 " を使用することです。ld.so.conf/lib/usr/lib/lib/termcap.so/usr/local/libld.so.conflibsld.so.confSONAME termcap.so「プログラムにバージョンをチェックさせて（すべてのライブラリがそれをサポートしています）、利用可能な機能を使用するようにしていましたが、古いリリースでは、計算速度が遅く、正しくコーディングする時間がないため、それがスキップされることがよくありました。

そうは言っても、この種のものを信頼する前に、特定のプラットフォームで徹底的にテストしてください。今日のリリース管理者は、過去のガイドラインやドキュメントを尊重するとは限りません。一部の UNIX の種類は、まったく異なる方法でリンクおよびロードします。rpath は、特定のディストリビューションに同梱されている ld に固有のものです。

最後に、前述のように、rpath はセキュリティ機能ですが、「強制アクセス制御」(MAC) やその他の手法は、ライブラリの読み取りと書き込みを制御するのに rpath と同等かそれ以上に効果的です。

今日のコンパイラを使用して rpath を制御することは、長くて複雑な make(1) スクリプトを考えると、ほとんど不可能であることが多いです。さらに悪いことに、一部のビルド スクリプトは、オプションとして —disable-rpath を提示しているにもかかわらず、これを無視します。コンパイルするすべての奇妙なプログラムのビルド スクリプトを修正するのは、時間がかかり、イライラさせられるだけでなく、おそらく実現不可能です。

単純な sh(1)「ラッパー」は、ld.bin という名前の実際の ld を呼び出すことができます。ラッパーは、 ld を呼び出す前に-rpathオプションをフィルター処理できます。

  #!/bin/sh 
# - ここで ld オプションをフィルター - ld.bin $opts  
   

ただし、ビルドによっては、ビルド ディレクトリに残る中間製品を見つけるために、rpath-link やLD_LIBRARY_PATHや$(TOP)/dir/foo.soではなく、rpath が誤って使用されることに注意してください。そのため、最終製品で rpath が逆方向に要求されます。これは、「rpath とは何か」に関する新しい問題です。

rpath と runpath の使用は、適用される値に攻撃者の制御下にあるディレクトリが含まれる場合にセキュリティ リスクをもたらす可能性があります。これには、定義された値が攻撃者の書き込み可能な場所を明示的に参照する場合だけでなく、. または .. の存在、$ORIGIN などを介して相対パスが使用される場合や、ディレクトリ ステートメントが未入力のままになっている場合も含まれます。特に、安全でないパスが使用されている場合、setUID バイナリが悪用される可能性があります。これを利用して、バイナリを騙し、攻撃者の制御下にあるいずれかのディレクトリから悪意のあるライブラリをロードさせることができます。

• DT_RPATHchrpath -実行可能ファイルの属性を変更し、それをDT_RUNPATH属性に変換するツール
• FreeBSD devel/chrpath ポート - 既存の ELF バイナリの DT_RPATH を変更するツール
• patchELF - ELF実行可能ファイルの動的リンカーとDT_RUNPATH属性を変更するための小さなユーティリティ。
• [1] - DT_RPATHへの攻撃を含むランタイムリンカーへの攻撃に関する論文