chroot如何影響動態鏈接？

Question

這是我的場景：

我創建了一個debootstrap ubuntu maverick（64位）環境。 我把它放在/env/mav/我的ubuntu（64位）清晰系統上。 我可以chroot到/env/mav並且可以完美地利用特立獨行的系統。

我甚至可以在chrooted環境之外使用清晰的程序。 那就是/env/mav/bin/ls會運行。

但是，我注意到如果我將LD_LIBRARY_PATH修改為/env/mav/lib [1] [2]

我運行的每一個程序（清醒和特立獨行）都會立即崩潰。 （例如ls導致段錯誤）。 kern.log顯示：

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

但是，很明顯，如果我chroot到/env/mav ，每個程序運行正常。 並不是所有的庫都只是從被監禁的（ /env/mav ） /lib讀取的？ 那么在這種情況下chroot和修改LD_LIBRARY_PATH之間的區別是什么？

此外，如果我：

mount -B /env /env/mav/env

然后chroot /env然后將LD_LIBRARY_PATH設置為/env/mav/lib ，一切都運行正常。

我對這里內部發生​​的事情感到茫然。 是否有某些ld內部存儲在某處？ chroot是否做了一些神奇的事情？

[1]用例是從正確綁定的特立獨行環境中運行程序，以便在特立獨行的監獄之外設置動態鏈接庫。

[2]這只是一個簡略的例子。 實際上/usr/lib等都包括在內。 包括特立獨行的環境/ lib“毒葯”的一切; 使用其他特立獨行的庫目錄沒有問題。

Answer 1

LD_LIBRARY_PATH是ld-linux.so程序/庫的選項。 該庫是一個動態鏈接器。 它的路徑“ /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然后它將嘗試使用$LD_LIBRARY_PATH env變量解析動態庫（你可以看到使用LD_DEBUG=all env變量的goind）

當你做chroot時，將使用特立獨行的/lib/ld-linux.so.2 。

我認為，有可能是主機系統之間的一些incompability ld-linux和客人（特立獨行）系統的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

在這里，我嘗試手動啟動guest的ld-linux，以覆蓋INTREP硬編碼路徑（是的，運行.so庫似乎相當不尋常，但這個庫是非常特殊的情況並且允許這種語法）。 如果這個命令有效，我的假設可能會很好。 如果沒有，還有其他解釋可能。