在Linux开发过程中，我们会遇到这样的情况，明明可执行程序elf与共享库so在同一个目录，但是进入此目录执行./elf 却会提示so找不到？这种情况对于从Windows平台过渡过来的程序员是比较费解的。这里其实就涉及到Linux上可执行程序搜索需要的库的一个范围和顺序问题。首先，是范围问题，我们可以通过查询ld的说明文档知晓范围。其次，是顺序问题，如果第三方程序制作了一个与系统库同名的so库，并把它放在了优先加载的位置，即优先于系统库目录的位置，定然就会发生劫持，这是一个风险点。
网络上比较流行的Linux动态库劫持的方式是通过/etc/ld.so.preload或者环境变量LD_PRELOAD来劫持的，这种方式很容易被发现，因为它会影响所有后续启动的进程，比如有些挖矿进程隐身的时候就使用了此技术，这种方式我们先不谈，本文，我们谈一谈库加载顺序可能导致的风险，这个风险不容易被发现，但值得警惕。
二：so共享库运行时加载顺序验证
1）准备
Linux共享库的运行时加载顺序为：
1：环境变量LD_LIBRARY_PATH指定的路径
2：连接时 -rpath指定的共享库查找路径
3：ldconfig 配置文件ld.so.conf指定的路径
4：/lib
5：/usr/lib
因为Windows搜索dll的路径会搜索本地目录和PATH路径，我们也捎带测试一下这两种情况。
在作者的机器上，/lib为/usr/lib的软链接，
所以，我们只测试前四种情况+PATH+本地!
为了公平验证所有运行时加载顺序，
我们在这几个目录都放置好同名但print输出不同的so库文件，-rpath指定好主程序的加载目录，配置好PATH路径，配置好ld.so.conf。运行主程序，查看输出结果，不断删除起作用的项，可逐一验证运行时加载顺序：
编写七个文件如下
user@kali:~/pro$ cat a1.c
#include <stdio.h>
void myprint()
{
printf("Hello a1[LD_LIBRARY_PATH]\n");
}
user@kali:~/pro$ cat a2.c
#include <stdio.h>
void myprint()
{
printf("Hello a2[rpath]\n");
}
user@kali:~/pro$ cat a3.c
#include <stdio.h>
void myprint()
{
printf("Hello a3[ld.so.conf]\n");
}
user@kali:~/pro$ cat a4.c
#include <stdio.h>
void myprint()
{
printf("Hello a4[/lib--/usr/lib]\n");
}
user@kali:~/pro$ cat a5.c
#include <stdio.h>
void myprint()
{
printf("Hello a5 PATH\n");
}
user@kali:~/pro$ cat a6.c
#include <stdio.h>
void myprint()
{
printf("Hello a6 local\n");
}
user@kali:~/pro$ cat main.c
#include <stdio.h>
extern void myprint();
int main()
{
myprint();
return 0;
}
编译和设置，步骤如下：
// 创建文件夹
user@kali:~/pro$ mkdir dir_ld_conf dir_path dir_ld_path dir_rpath
其中：
dir_ld_conf 用来验证ld.so.conf的作用
dir_ld_path 用来验证LD_LIBRARY_PATH的作用
dir_path 用来验证环境变量PATH的作用
dir_rpath 用来验证链接时rpath的作用
// a1.c 验证LD_LIBRARY_PATH
user@kali:~/pro$ gcc -shared -o ./dir_ld_path/liba.so a1.c
user@kali:~/pro$ export LD_LIBRARY_PATH=/home/user/pro/dir_ld_path
user@kali:~/pro$ echo $LD_LIBRARY_PATH
/home/user/pro/dir_ld_path
// a2.c 验证rpath
user@kali:~/pro$ gcc -shared -o ./dir_rpath/liba.so a2.c
// a3.c 验证ld.so.conf
user@kali:~/pro$ gcc -shared -o ./dir_ld_conf/liba.so a3.c
// 编辑，加入/home/user/pro/dir_ld_conf
user@kali:~/pro/dir_ld_conf$ sudo vim /etc/ld.so.conf
// 刷新缓存
user@kali:~/pro/dir_ld_conf$ sudo ldconfig
// a4.c 验证/lib /usr/lib
user@kali:~/pro$ sudo gcc -shared -o /lib/liba.so a4.c
// a5.c 验证PATH
user@kali:~/pro$ gcc -shared -o ./dir_path/liba.so a5.c
user@kali:~/pro$ export PATH=/home/user/pro/dir_path:$PATH
user@kali:~/pro$ echo $PATH
/home/user/pro/dir_path:/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
// a6.c 验证本地
user@kali:~/pro$ gcc -shared -o liba.so a6.c
// 编译主程序[带rpath]
user@kali:~/pro$ gcc -o main main.c -L. -la -Wl,-rpath,dir_rpath
此时目录结构如下：
我们看一下动态节.dynamic的内容：
可见rpath指定的路径已经被写入了可执行文件中。
2）手工验证
一切就绪，我们开始验证：
user@kali:~/pro$ ./main
Hello a1[LD_LIBRARY_PATH]
可见 LD_LIBRARY_PATH第一个起作用
删除dir_ld_path之后
user@kali:~/pro$ ./main
Hello a2[rpath]
可见-rpath连接选项第二个起作用
删除dir_rpath之后
user@kali:~/pro$ ./main
Hello a3[ld.so.conf]
可见ld.so.conf配置文件第三个起作用
删除 dir_ld_conf之后
user@kali:~/pro$ ./main
Hello a4[/lib--/usr/lib]
可见 /lib 目录生效，第四个起作用
删除/lib/liba.so之后
user@kali:~/pro$ ./main
./main: error while loading shared libraries: liba.so: cannot open shared object file: No such file or directory
可见只有这四个可以起作用，我们设置的PATH中的路径和本地路径都没有起作用。
如果感兴趣的话，也可以用strace追踪一下main的系统调用过程，也能发现调用过程是这样的顺序。
至此，可以得出结论：Linux的共享库so的寻找顺序为：
1：LD_LIBRARY_PATH
2：-rpath连接选项
3：ld.so.conf配置文件
4：/lib和/usr/lib
3）源代码验证
既然Linux是开源系统，最权威的验证方式，当然是源代码了，库的寻找顺序，系统是交给动态链接器来管理的，Linux的ELF动态链接器是Glibc的一部分，作者从glibc-2.29版本中的dl-load.c文件中找到这么一个函数记载了运行时加载顺序的寻找过程：
struct link_map
_dl_map_object (struct link_map loader, const char *name,
int type, int trace_mode, int mode, Lmid_t nsid)
几个主要的代码片段如下：
最开始是RPATH与RUNPATH同时存在时的处理方式，RPATH是旧式的编译器用的方式，RUNPATH是最新的编译器支持的方式，这两种方式可以通过在链接时指定–enable-new-dtags/–disable-new-dtags来控制。
总体的处理逻辑为：
if(对象没有RUNPATH) {
if（对象有RPATH）{
使用RPATH
} else {
递归查找加载者(loader)的RPATH（或者有RUNPATH退出）
}
if(可执行程序没有RUNPATH) {
使用可执行程序的RPATH
}
}
查找LD_LIBRARY_PATH
查找正被加载对象的RUNPATH
查找ld.so.cache
查找默认路径
作者的编译器是最新的，默认就会使用RUNPATH。
从源码也可以看出，我们之前的验证是正确的。
使用–disable-new-dtags或旧式编译器的人可能会发现有时候-rpath优先于LD_LIBRARY_PATH，原因就在于程序进入了RUNPATH与RPATH的处理逻辑。可以使用readelf -d 查看动态节到底有没有RPATH或RUNPATH来进行分析
三：运行时加载顺序可能的风险分析
明白了这些运行时加载顺序，最后简单概括一下：
1：LD_LIBRARY_PATH的环境变量的影响范围是全局的，同LD_PRELOAD影响一样，会有风险点，过多的使用可能会影响到其他应用程序的运行，所以多用于调试模式。
2：-rpath链接选项是程序生成时指定的，一般程序运行前都已经生成了，所以这项暂时构成不了威胁。
3：ld.so.conf配置文件与LD_LIBRARY_PATH一样，都有同样的风险
4：/lib和/usr/lib 是系统文件，所属权限属于root，因为每个so库在各Linux系统中的位置有差异，要在这个位置预防so动态库劫持，就需要对库的位置进行精确定位，精准拦截。