☰

Linux 的动态链接器搜索路径的顺序是什么？

tag-icon • tag-icon linux dynamic-linking
Linux 的动态链接器搜索路径的顺序是什么？

这不是重复的，因为这是处理我在使用时注意到的一个特性/etc/ld.so.conf。

为了获取动态链接器搜索库的路径，我运行命令ldconfig -v | grep -v "^"$'\t' | sed "s/:$//g"。当/etc/ld.so.conf其中没有列出路径时。上一个命令的输出是

/lib
/usr/lib

我认为它是/lib先搜索，然后搜索/usr/lib。当我添加新路径（例如/usr/local/lib, to/etc/ld.so.conf然后 remake ）时/etc/ld.so.cache，输出ldconfig -v | grep -v "^"$'\t' | sed "s/:$//g"变为

/usr/local/lib
/lib
/usr/lib

我觉得这很奇怪，因为如果我正确地认为列出的目录的搜索顺序是从上到下，那么会在 和 之前搜索其他/lib目录/usr/lib。在可信目录之前搜索其他目录本身并不奇怪，但是当/lib在 之前搜索时/usr/lib，那就很奇怪了，因为/bin&是在& in 中/sbin搜索的。/usr/bin/usr/sbinPATH

即使ldconfig -v | grep -Ev "^"$'\t' | sed "s/:$//g"从下到上搜索 列出的路径，它仍然是一个倾斜的顺序，因为将在受信任的目录之后搜索其他目录，而在/lib之后搜索/usr/lib。

ld.so那么，搜索库路径的顺序是什么？为什么/lib之前被搜索过/usr/lib？如果不是，那么为什么要在之后搜索其他目录/lib？

答案1

该顺序记录在动态链接器的手册中，即ld.so。这是：

  1. 目录来自LD_LIBRARY_PATH;
  2. 目录来自/etc/ld.so.conf;
  3. /lib；
  4. /usr/lib。

（我稍微简化了一下，请参阅手册以了解完整的详细信息。）

当您认为这是使用自定义库覆盖默认位置中的库的唯一方法时，该顺序是有意义的。LD_LIBRARY_PATH是一个用户设置，它必须位于其他设置之前。/etc/ld.so.conf是本地设置，它位于操作系统默认值之前。因此，作为用户，如果我想运行具有不同版本的库的程序，我可以运行包含LD_LIBRARY_PATH该不同库版本的位置的程序。作为管理员，我可以将库的不同版本放入/usr/local/lib并/usr/local/lib列出/etc/ld.so.conf。

信任与此无关。此搜索路径上列出的任何目录都必须是可信的，因为任何库最终都可能从那里加载。理论上，您可以列出系统上“需要更多信任”的所有程序使用的库名称，并确保所有这些库都存在于“最受信任”的目录中，然后“不太受信任”的目录就不会出现如果它们位于搜索路径上更受信任的目录之后，则可以使用它们，但“需要较少信任”的程序除外。但这将是极其脆弱的。这也毫无意义：如果攻击者可以注入 的值LD_LIBRARY_PATH或 的元素/etc/ld.so.conf，他们肯定有更直接的途径来执行任意代码，例如注入 、PATHof的值LD_PRELOAD等。对库加载路径的信任确实当执行跨越信任边界时，即当运行具有附加权限的程序时（例如 setuid/setgid 程序或 via sudo），这很重要。在这种情况下发生的情况是LD_LIBRARY_PATH被清空了。

至于/libvs /usr/lib，这并不重要：它们由同一实体（操作系统）提供，并且不应该存在同时存在于两者中的库。/lib首先列出是有意义的，因为它提供了（非常微小的）性能优势：最常用的库，尤其是小型基本程序（其加载时间占总运行时间的比例高于大型、长时间运行的程序）使用的库，位于 中/lib。

相关内容