テクノロジー · 実用ガイド
ld.so の「object from LD_PRELOAD cannot be preloaded」：ライブラリを変える前に注入元を特定する
警告が証明するのは、要求されたオブジェクトを動的ローダーが拒否したことだけです。誰が要求したかを保存し、全注入元と ELF 境界を確認して、所有する設定だけを修正します。
このメッセージは対象プログラムが完全に起動する前に動的ローダーが出します。追加オブジェクトが要求され無視されたことを示しますが、通常依存関係がすべて欠落したとは限りません。
所有者からオブジェクトまでの台帳を作り、環境、ランチャー、サービス、/etc/ld.so.preload のどれが要求したかを特定してから、パス、ELF、マッピング、安全実行を分類します。
1. 警告と実行文脈を固定する
オブジェクト文字列、括弧内理由、正確なコマンド、実行ファイル、ユーザー、作業ディレクトリ、時刻を保存します。cannot open、failed to map、安全モードは別の所見です。
安全な場合だけ一度再現し、対話シェル、ラッパー、サービス、コンテナ、特権プログラムのどれかを記録します。所有者未確認のパッケージを先に再導入しません。
2. すべての注入元を特定する
プロセス環境、シェル初期化、ラッパー、サービスの Environment/EnvironmentFile、コンテナ設定を調べ、/etc/ld.so.preload は別に確認します。
一つのシェルで unset しても残る警告は別の所有者の証拠です。編集前に値と出所を保存します。
3. パス、アクセス、ELF 身元を分類する
ローダーと同じ文字列を確認し、存在、型、所有者、権限、マウントを記録します。ディレクトリ、切れたリンク、読めないファイル、分割されたトークンは無効です。
file と readelf で実行ファイルとオブジェクトのクラス、データ符号、OS/ABI、マシンを比較します。調査のために不審な物件を実行しません。
4. マッピング、再配置、安全実行を分ける
パスと ELF が一致したら同じ非特権試験で診断を集め、セグメント、依存関係、再配置、シンボル、バージョンを確認します。
set-ID や capability 付き実行では LD_PRELOAD が制限されます。権限を弱めたり任意物件を信頼ディレクトリへ置いたりしません。
5. 所有する設定を直して検証する
証明したシェル、ラッパー、サービス、コンテナ、/etc/ld.so.preload だけを修正します。パッケージ所有と ABI を証明してから復元します。
同じ実行ファイルを無注入で試し、必要なら検証済み物件を注入します。警告、ロード状態、機能、他プロセスへの影響を確認して完了です。
