chroot如何影响动态链接? [英] How does chroot affect dynamic linking?

问题描述

这是我遇到的情况:

我创建了一个debootstrap ubuntu特立独行(64位)环境.我将其放置在我的ubuntu(64位)透明系统上的/env/mav/上.我可以将chroot转换为/env/mav，并且可以完美地利用特立独行的系统.

I've created a debootstrap ubuntu maverick (64-bit) environment. I placed it at /env/mav/ on my ubuntu (64-bit) lucid system. I can chroot into /env/mav and can utilize a maverick system perfectly.

我什至可以在chroot环境之外使用清晰的程序.即/env/mav/bin/ls将运行.

I can even use the lucid programs fine outside the chrooted environment. That is /env/mav/bin/ls will run.

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

However, I noticed that if I modify LD_LIBRARY_PATH to be /env/mav/lib [1] [2]

我运行的每个程序(清晰和特立独行的)都会立即崩溃. (例如ls导致段错误). kern.log显示:

every single program (both lucid and maverick) I run will crash instantly. (e.g. ls results in a segfault). kern.log shows:

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

但是，很明显，如果我chroot进入/env/mav，则每个程序都运行良好.而且不是所有的库都只是从被监禁的(/env/mav)/lib中读取的吗?那么在这种情况下chroot和修改LD_LIBRARY_PATH有什么区别?

However, clearly if I chroot into /env/mav, every program is running fine. And aren't all libraries just being read from the jailed (/env/mav) /lib? So what is the difference between chroot and modifying LD_LIBRARY_PATH in this context?

此外，如果我:

mount -B /env /env/mav/env

然后chroot /env然后将LD_LIBRARY_PATH设置为/env/mav/lib，一切仍然可以正常运行.

and then chroot /env and then set LD_LIBRARY_PATH to be /env/mav/lib, everything still runs fine.

我对这里的内部情况不知所措.是否有一些ld内部零件存储在某个地方? chroot会做一些神奇的事情吗?

I'm at at a loss for what's going internally here. Are there some ld internals stored somewhere? Does chroot do something magical?

[1]用例是从特立独行的环境中运行程序，该程序正确地绑定到特立独行的监狱外部的特立独行的动态链接库.

[1] Use case is to run programs from the maverick environment bound correctly to maverick dynamically linked libraries outside the maverick jail.

[2]这只是一个简短的示例.实际上，都包含/usr/lib等.包括特立独行环境的/lib毒化"一切；使用其他特立独行的库目录没有任何问题.

[2] This is just an abridged example. In reality /usr/lib, etc. are all included. Including the maverick environment's /lib "poisons" everything; there are no problems using the other maverick library directories.

推荐答案

LD_LIBRARY_PATH是ld-linux.so程序/库的选项.该库是一个动态链接器.它的路径"/lib/ld-linux.so.2"硬编码在(几乎)ubuntu中所有动态链接的程序的ELF标头(INTREP字段)中.我的意思是，当Linux内核运行二进制文件时，它对LD_LIBRARY_PATH的特殊含义一无所知.

LD_LIBRARY_PATH is the option of ld-linux.so program/library. This library is a dynamick linker. It's path "/lib/ld-linux.so.2" is hardcoded in (almost) all dynamically linked programms in ubuntu, in ELF header (INTREP field). I mean that, when Linux kernel runs binary file, it know nothing about special meaning of 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变量来查看动态)

the root system's /lib/ld-linux.so.2 will be used and then it will try to resolve dynamic libraries using $LD_LIBRARY_PATH env variable (you can see what's goind using LD_DEBUG=all env variable)

当您执行chroot时，将使用特立独行的/lib/ld-linux.so.2.

And when you do a chroot, maverick's /lib/ld-linux.so.2 will be used.

我认为，主机系统的ld-linux与guest(maverick)系统的libc.so之间可能存在某些不兼容性(因为ld-linux是glibc/eglibc软件包的一部分，并且使用了libc.so的某些内容).

I think, there can be some incompability between host system's ld-linux and guest(maverick) system's libc.so (because ld-linux is part of glibc/eglibc package and it uses something from libc.so).

要检验我的假设，请尝试运行(环境变量设置的bash语法):

To test my assumption, try to run (bash syntax of env variable setting):

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

在这里，我尝试手动启动guest虚拟机的ld-linux，以覆盖INTREP硬编码路径(是的，运行.so库似乎很不寻常，但是该库是非常特殊的情况，并允许使用此语法) .如果该命令有效，我的假设可能很好.如果没有，还有其他解释可能.

Here I try to start guest's ld-linux manually, in order to overwrite INTREP hardcoded path (Yes, this seems rather unusual to run an .so library, but this library is the very special case and allows for this syntax). If this command will work, my assumption may be good. If not, there are other explainations possible.

这篇关于chroot如何影响动态链接?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！