Как chroot влияет на динамическое связывание? - PullRequest
Новая
       38

Как chroot влияет на динамическое связывание?

6 голосов
/ 04 ноября 2011

Вот мой сценарий:

Я создал среду debootstrap ubuntu maverick (64-bit).Я поместил его на /env/mav/ в моей (64-битной) системе Ubuntu.Я могу chroot в /env/mav и могу отлично использовать систему maverick.

Я могу даже использовать программы lucid отлично вне среды chroot.То есть /env/mav/bin/ls будет выполняться.

Однако я заметил, что если я изменю LD_LIBRARY_PATH, чтобы он был /env/mav/lib [1] [2]

каждой отдельной программой (как lucid, так и maverick)) Я бегу вылетит мгновенно.(например, ls приводит к segfault).kern.log показывает: 

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

Тем не менее, ясно, если я chroot в /env/mav, каждая программа работает нормально.И не все ли библиотеки читаются из тюрьмы (/env/mav) /lib?Так в чем же разница между chroot и изменением LD_LIBRARY_PATH в этом контексте?

Кроме того, если I: 

mount -B /env /env/mav/env

, а затем chroot /env, а затем установите LD_LIBRARY_PATH вбыть /env/mav/lib, все по-прежнему работает нормально.

Я в растерянности из-за того, что происходит здесь внутри.Где-то хранятся какие-то внутренние компоненты ld?Chroot делает что-то волшебное?

[1] Вариант использования - запуск программ из среды maverick, правильно привязанных к maverick динамически связанным библиотекам за пределами тюрьмы maverick.

[2] Это всего лишьсокращенный пример.На самом деле /usr/lib и т. Д. Все включено.Включая / maverick среды / lib "отравляет" все;нет проблем с использованием других каталогов библиотеки maverick.

1 Ответ

6 голосов
/ 04 ноября 2011

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)

А когда вы выполните chroot, maverick's /lib/ld-linux.so.2 будет использоваться.

Я думаю, может быть некоторая несовместимость между ld-linux хост-системы и libc.so гостевой (maverick) системы (потому что ld-linux является частью пакета glibc / eglibc и использует что-тоиз libc.so).

Чтобы проверить мои предположения, попробуйте выполнить (синтаксис bash для установки переменной env): 

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

Здесь я пытаюсь запустить гостевой ld-linux вручную, вчтобы перезаписать INTREP жестко закодированный путь (да, запуск библиотеки .so кажется довольно необычным, но эта библиотека - особый случай и допускает такой синтаксис).Если эта команда сработает, моё предположение может быть хорошим.Если нет, возможны другие объяснения.

...