6

これが私が持っているシナリオです：

debootstrap ubuntu maverick（64ビット）環境を作成しました。私はそれを/env/mav/私のubuntu（64ビット）lucidシステムに配置しました。私は異端者のシステムに完全にchroot入ることができ、それを利用することができます。/env/mav

私は、chrootされた環境の外でも、明快なプログラムをうまく使用することができます。それが/env/mav/bin/ls実行されます。

しかし、 [1][2]に変更LD_LIBRARY_PATHすると気づきました/env/mav/lib

私が実行するすべてのプログラム（lucidとmaverickの両方）は即座にクラッシュします。（たとえば、lsはセグメンテーション違反になります）。kern.logは次のことを示しています。

segfault at 7fece284aa18 ip 00007fece284aa18 sp 00007fff32028158 error 15

ただし、明らかに、私がにchroot入る/env/mavと、すべてのプログラムが正常に実行されています。そして、すべてのライブラリがjailed（/env/mav）から読み取られているだけではありません/libか？では、このコンテキストでのchroot変更と変更の違いは何ですか？LD_LIBRARY_PATH

さらに、私が：

mount -B /env /env/mav/env

その後chroot /env、に設定LD_LIBRARY_PATHしても/env/mav/lib、すべてが正常に実行されます。

私はここで内部的に起こっていることに途方に暮れています。どこかに保存されている古い内部構造はありますか？chrootは魔法のようなことをしますか？

[1]ユースケースは、マーベリック刑務所の外にあるマーベリックダイナミックリンクライブラリに正しくバインドされたマーベリック環境からプログラムを実行することです。

[2]これは単なる簡略化された例です。実際/usr/libには、などがすべて含まれています。異端者の環境の/libを含めるとすべてが「毒」になります。他のマーベリックライブラリディレクトリを使用しても問題はありません。

4

1 に答える 1

7

LD_LIBRARY_PATHは、ld-linux.soプログラム/ライブラリのオプションです。このライブラリはdynamickリンカーです。そのパス" /lib/ld-linux.so.2"は、UBuntuの（ほぼ）動的にリンクされたすべてのプログラムのELFヘッダー（INTREPフィールド）にハードコードされています。つまり、Linuxカーネルがバイナリファイルを実行するとき、LD_LIBRARY_PATHの特別な意味については何も知りません。

だから、あなたが走るとき

 LD_LIBRARY_PATH=/env/mav/ /env/mav/bin/ls

ルートシステムの/lib/ld-linux.so.2が使用され、env変数を使用してダイナミックライブラリを解決しようとし$LD_LIBRARY_PATHます（env変数を使用して何が起こっているかを確認できLD_DEBUG=allます）

そして、chrootを実行すると、maverick/lib/ld-linux.so.2が使用されます。

ld-linuxホストシステムとguest（maverick）システムの間に互換性がない可能性があると思いますlibc.so（ld-linuxはglibc / eglibcパッケージの一部であり、libc.soの何かを使用しているため）。

私の仮定をテストするには、（env変数設定のbash構文）を実行してみてください。

 LD_LIBRARY_PATH=/env/mav/ /env/mav/lib/ld-linux.so.2 /env/mav/bin/ls

ここでは、INTREPハードコードパスを上書きするために、ゲストのld-linuxを手動で起動しようとしています（はい、これは.soライブラリを実行するのはかなり珍しいようですが、このライブラリは非常に特殊なケースであり、この構文を使用できます）。このコマンドが機能する場合、私の仮定は良いかもしれません。そうでない場合は、他の説明が可能です。

于 2011-11-04T02:44:32.140 に答える