|
|
实际上一切 程序执行都依赖于库。在包括Linux的大多数现代类Unix系统中，程序缺省使用动态连接库（DLL）进行编译。这样就可以更新某个库，一切 使用该库的程序假如 可能的话，都将使用新的（希望有所改良 的）版本。
动态连接库通常被放在若干特殊目录下。通常这些目录包括/lib、/usr/lib、有关PAM模块的/lib/security、有关X-windows的/usr/X11R6/lib和/usr/local/lib.
对于库的命名和进行库的符号连接有些特殊商定 ，这样就可以更新库，同时继续支持需要. 使用不具有反向兼容的老版本库的程序。在执行特定程序时可以掩盖 某个指定库，甚至只掩盖 某个库里的指定函数。这是类Unix系统相对于类Windows 的一个实际优点；我相信类Unix系统有一个更好的系统来处理库的更新，这也是Unix和Linux系统被觉得 比基于Windows的系统更稳定的原因。
在包括一切 Linux系统的基于GNU glibc的系统中，程序启动时自动寻找的目录列表存储在文件/etc/ld.so.conf中。很多源于Red Hat的发行版一般在文件/etc/ld.so.conf中不包含/usr/local/lib.我觉得 这是个Bug,要在源于Red Hat的系统里运行很多程序都需要. 进行一个通用的"修复",把/usr/local/lib加入/etc/ld.so.conf.
假如 只是想掩盖 某个库里的若干函数，而想保留 该库的其它部分，可以在/etc/ld.so.preload中输入要掩盖 的库名（。o文件）；这些"预载入"的库会优先于标准库使用。通常这种预载入文件是用于紧急补丁的；发行版在发行时一般不会包含这样的文件。
在程序启动时寻找一切 这些目录太花时间，所以实际上使用了一个cache管理方法。程序ldconfig（8）缺省读入文件/etc/ld.so.conf,在动态连接目录里建立相应的符号连接（这样就遵照 了标准商定 ），然后把cache写入/etc/ld.so.cache,这样就可以被其它程序使用了。所以一旦增加一个DLL,或删除一个DLL,或者DLL目录集发作 改动 ，ldconfig就要运行一次；在安装库时，运行ldconfig通常是软件包管理程序需要. 执行的一个步骤。在启动时，程序使用动态加载程序来读入文件/etc/ld.so.cache,然后载入其所需的库。
各种环境变量可以控制这一过程，而且事实上也有允许掩盖 此过程的环境变量（所以可以在某次特别的执行过程中暂时 替换某个不同的库）。在Linux下，环境变量LD_LIBRARY_PATH是一组用逗号隔开的目录，在查找标准目录集之前先查找这些库；这在调试新库或为特殊目的使用非标准库时很有用。变量LD_PRELOAD列出了掩盖 标准集的函数所在的目的 文件，就像/etc/ld.so.preload一样。
假如 不采取特别的措施，允许用户控制动态连接库会对setuid/setgid程序形成 灾难性的后果。因而 在实现GNU glibc时，假如 是setuid或setgid程序，将疏忽 这些变量（和其它类似的变量），或者严厉 限制这些变量所起的作用。GNU的glibc库通过检查程序的证明来确定其是否为setuid或setgid程序；假如 uid和euid不同，或者gid和egid不同，则库就假定 该程序为setuid/setgid程序（或者为其子程序），然后严厉 限制它控制连接的能力。假如 载入GNU的glibc库，就可以看到这种状况 ；
请特别阅读一下文件elf/rtld.c和sysdeps/generic/dl-sysdep.c.这就意味着假如 使uid和gid等于euid和egid,再调用程序，这些变量就具有完全的效能 。其它类Unix系统处理这些状况 有所不同，但原因相同：一个setuid/setgid程序不应遭到 环境变量集的过分影响。
|
|
|
|
|
|
|
|
|
|
