Chroot ảnh hưởng đến liên kết động như thế nào?

Question

Đây là kịch bản tôi đang có:

Tôi đã tạo môi trường debootstrap ubuntu maverick (64-bit). Tôi đặt nó ở /env/mav/ trên hệ thống ubuntu (64-bit) sáng suốt của tôi. Tôi có thể chroot vào /env/mav và có thể sử dụng hệ thống maverick một cách hoàn hảo.

Tôi thậm chí có thể sử dụng các chương trình sáng suốt bên ngoài môi trường chroot. Đó là /env/mav/bin/ls sẽ chạy.

Tuy nhiên, tôi nhận thấy rằng nếu tôi sửa đổi LD_LIBRARY_PATH là /env/mav/lib [1] [2]

mọi chương trình duy nhất (cả sáng suốt và Maverick) Tôi chạy sẽ sụp đổ ngay lập tức. (ví dụ: kết quả ls trong một segfault). kern.log cho thấy:

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

Tuy nhiên, rõ ràng nếu tôi chroot vào /env/mav, mọi chương trình đang chạy tốt. Và không phải tất cả các thư viện chỉ được đọc từ nhà tù (/env/mav) /lib? Vì vậy, sự khác biệt giữa chroot và sửa đổi LD_LIBRARY_PATH trong ngữ cảnh này là gì?

Hơn nữa, nếu tôi:

mount -B /env /env/mav/env 

và sau đó chroot /env và sau đó thiết lập LD_LIBRARY_PATH là /env/mav/lib, mọi thứ vẫn chạy tốt.

Tôi không hài lòng với những gì đang diễn ra ở đây. Có một số nội bộ ld được lưu trữ ở đâu đó? Chroot có làm điều gì đó huyền diệu không?

[1] Trường hợp sử dụng là chạy các chương trình từ môi trường maverick bị ràng buộc chính xác tới các thư viện được liên kết động với maverick bên ngoài nhà tù maverick.

[2] Đây chỉ là một ví dụ tóm tắt. Trong thực tế, /usr/lib, v.v ... đều được bao gồm. Bao gồm cả các chất độc của môi trường/lib "chất độc" tất cả mọi thứ; không có vấn đề gì khi sử dụng các thư mục maverick khác.

Answer 1

LD_LIBRARY_PATH là tùy chọn ld-linux.so chương trình/thư viện. Thư viện này là một liên kết động. Đường dẫn "/lib/ld-linux.so.2" được mã hóa cứng (gần như) tất cả các chương trình được liên kết động trong ubuntu, trong tiêu đề ELF (trường INTREP). Tôi có nghĩa là, khi hạt nhân Linux chạy tập tin nhị phân, nó không biết gì về ý nghĩa đặc biệt của LD_LIBRARY_PATH.

Vì vậy, khi bạn chạy

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

/lib/ld-linux.so.2 hệ thống rễ sẽ được sử dụng và sau đó nó sẽ cố gắng giải quyết các thư viện động sử dụng $LD_LIBRARY_PATH biến env (bạn có thể xem những gì goind sử dụng LD_DEBUG=all biến env)

Và khi bạn thực hiện một chroot, maverick's /lib/ld-linux.so.2 sẽ được sử dụng. Tôi nghĩ rằng, có thể có một số không tương thích giữa hệ thống máy chủ ld-linux và hệ thống của khách (maverick) libc.so (vì ld-linux là một phần của gói glibc/eglibc và nó sử dụng cái gì đó từ libc.so).

Để kiểm tra giả thuyết của tôi, cố gắng chạy (cú pháp bash của bối cảnh biến env):

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

Ở đây tôi cố gắng để bắt đầu ld-linux khách bằng tay, để ghi đè lên đường INTREP hardcoded (Vâng, đây có vẻ khá bất thường khi chạy thư viện .so, nhưng thư viện này là trường hợp rất đặc biệt và cho phép cú pháp này). Nếu lệnh này sẽ hoạt động, giả định của tôi có thể tốt. Nếu không, có những giải thích khác có thể.