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，对/etc/ld.so.conf再重拍/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＆/sbin在/usr/bin＆/usr/sbinin 之后搜索PATH。

即使被列出的路径ldconfig -v | grep -Ev "^"$'\t' | sed "s/:$//g"是从底部寻找到顶部，它仍然是一个扭曲的排序，因为额外的目录会在受信任的人后，而被搜索/lib会后进行搜索/usr/lib。

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

该顺序记录在动态链接器的手册（）中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，那么他们肯定具有执行任意代码的更直接途径，例如注入的值PATH，，LD_PRELOAD当执行越过信任边界时，即运行具有附加特权的程序（例如setuid / setgid程序或via sudo）时，对库加载路径的信任就很重要。在这种情况下发生的是LD_LIBRARY_PATH被清空。

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