☰

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.

相關內容