Linuxfunction(setcap)似乎禁用了LD_LIBRARY_PATH

我使用LD_LIBRARY_PATH为应用程序设置某个用户库的path。 但是,如果我在这个应用程序设置function

 sudo setcap CAP_NET_BIND_SERVICE=eip myapplication 

那么LD_LIBRARY_PATH似乎被忽略。 当我启动程序时,Linux抱怨它找不到某个共享库

我猜想有一些保护措施可以阻止盗用扩展权的应用程序被劫持。 有没有解决方法?

正如其他答案中已经指出的那样,这种行为是有意的。 如果您可以自己编译(或至少链接)应用程序,则有一些解决方法。 然后,您可以将-Wl,-rpath <yourDynamicLibraryPath>传递给gcc或-rpath <yourDynamicLibraryPath>为ld,并且在执行时不必指定LD_LIBRARY_PATH

sudo的手册页说明:

请注意,大多数操作系统上的动态链接程序将删除可以控制setuid可执行文件环境(包括sudo)的动态链接的变量。 根据操作系统的不同,这可能包括RLD *,DYLD *,LD_ ,LDR_ ,LIBPATH,SHLIB_PATH等等。 这些类型的变量在sudo甚至开始执行之前从环境中被删除,因此sudo不可能保存它们。

正如这个链接所解释的 ,这样做的实际机制是glibc。 如果UID与EUID不匹配(包括sudo在内的任何setuid程序都是这种情况),那么将删除所有“不安全的环境变量”。 因此,具有提升特权的程序不会改变。

是的,出于安全原因,它被禁用。

在linux上解决这个问题的方法如下:

进入目录$cd /etc/ld.so.conf.d/创建一个新文件$ touch xyz.conf使用任何编辑器打开这个文件$vi xyz.conf

例如,如果你的路径如下所示,在这个文件中逐行添加你的动态库路径:

/home/xyz/libs1:/home/xyz/libs2/:/home/xyz/libs3/然后在这个文件中应该有三个条目如下: /home/xyz/libs1/ /home/xyz/libs2/ /home/xyz/libs3/

然后保存该文件并执行以下命令: $ldconfig

以上所有操作都需要从root登录进行

另一种可以考虑的方法是使用patchelf来“纠正”编译得不好的ELF共享库和/或可执行文件来设置rpath。 https://nixos.org/patchelf.html

ld.so.conf并不总是肯定的。 它会工作,如果你正在运行的是正确编译。 在我的情况下,对于一个特定的打包供应商的apache产品,它的编译如此糟糕:他们甚至没有使用独特的.so文件名,所以它们与基本RHEL库中的RPMs的.so文件名冲突,提供了一些非常关键的常用库。 所以这是隔离他们如何使用的唯一选择。 对供应商的lib路径中的共享对象使用ld.so.conf将会带来很多东西,包括yum,以及系统范围内的glibc共享库故障。