Linux功能（setcap）似乎禁用LD_LIBRARY_PATH

我使用LD_LIBRARY_PATH來爲應用程序設置某個用戶庫的路徑。但是，如果我在這個應用程序設置功能Linux功能（setcap）似乎禁用LD_LIBRARY_PATH

sudo setcap CAP_NET_BIND_SERVICE=eip myapplication

然後LD_LIBRARY_PATH似乎被忽略。當我啓動該程序時，Linux抱怨它無法找到某個共享庫。

我想有些保護措施可以阻止應用程序被盜用。有沒有解決方法？

來源

2012-03-23 Lorenzo Pistone

是的，它出於安全原因被禁用。

來源

2012-04-18 17:57:58

https://bugzilla.redhat.com/show_bug.cgi?id=448594 – mpe 2012-08-15 13:44:17

的man page爲sudo解釋說：

注意，在大多數操作系統動態鏈接程序會刪除變量可以從 setuid可執行文件，包括sudo的環境控制動態鏈接。根據操作系統，這可能包括RLD *，DYLD *，LD_ ，LDR_，LIBPATH，SHLIB_PATH和其他。在sudo甚至開始執行之前，這些類型的變量將從環境中刪除，因此，不可能爲sudo保留它們。

作爲this link explains，這樣做的實際機制是glibc。如果UID與EUID不匹配（setuid程序包括sudo），則所有「不安全的環境變量」將被刪除。因此，具有提升權限的程序不會改變。

來源

2012-08-10 20:02:48 chrisaycock

這一切都很好，但setcap不會更改UID或EUID。它確實增加了功能（「提升的權限」）。 – reinierpost 2014-06-25 15:42:13

正如其他答案中所述，此行爲是有意的。如果您可以自己編譯（或至少鏈接）應用程序，則有一些解決方法。然後你可以通過-Wl,-rpath <yourDynamicLibraryPath>到gcc或-rpath <yourDynamicLibraryPath>到ld，你不需要指定LD_LIBRARY_PATH在執行。

來源

2012-08-14 15:15:05 scai

謝謝，它像一個魅力。 – 2015-03-20 16:04:53

該解決方案在Linux上這個問題如下：

去目錄 $cd /etc/ld.so.conf.d/ 創建一個新的文件 $觸摸xyz.conf 使用任何編輯器打開這個文件 $vi xyz.conf

添加您的動態庫路徑在這個文件中，例如逐行如果你的路徑如下：

/home/xyz/libs1:/home/xyz/libs2/:/home/xyz/libs3/ 那麼就應該在這個文件中的三個條目，如下所示： /home/xyz/libs1/ /home/xyz/libs2/

然後保存這個文件並執行以下命令： $ldconfig

以上所有操作都需要從根登錄進行

來源

2014-02-28 05:42:40 user2706978

要考慮的一種替代方法是使用patchelf來「糾正」編譯不良的ELF共享庫和/或可執行文件來設置rpath。 https://nixos.org/patchelf.html

ld.so.conf並不總是可以肯定的。它會工作，如果你正在運行的是正確編譯。就我而言，使用特定打包供應商的apache產品時，它的編譯如此糟糕：它們甚至沒有使用唯一的.so文件名，因此它們與基本RHEL存儲庫中RPMs的.so文件名衝突，這些文件夾提供了一些非常關鍵的常用庫。所以這是隔離它們如何被使用的唯一選擇。對供應商lib路徑中的這些共享對象使用ld.so.conf可能會讓系統範圍內的許多東西（包括yum）以及glibc共享庫故障風靡。

來源

2015-07-10 05:47:00

Linux功能（setcap）似乎禁用LD_LIBRARY_PATH

回答

相關問題