動態連接庫通常被放在若干特殊目錄下。通常這些目錄包括/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程序不應受到環境變量集的過分影響。