Linux功能(setcap)似乎禁用了LD_LIBRARY_PATH

Question

我用来LD_LIBRARY_PATH为应用程序设置某个用户库的路径.但是如果我在这个应用程序上设置功能

sudo setcap CAP_NET_BIND_SERVICE=eip myapplication

然后LD_LIBRARY_PATH似乎被忽略了.当我启动程序时,Linux抱怨它无法找到某个共享库.

我猜这里有一些保护措施,以防止具有扩展权限的应用程序被劫持.有解决方法吗？

Answer 1

正如其他答案中所述,这种行为是有意的.如果您可以自己编译(或至少链接)应用程序,则有某种解决方法.然后你可以传递-Wl,-rpath <yourDynamicLibraryPath>给gcc或-rpath <yourDynamicLibraryPath>ld,你不必LD_LIBRARY_PATH在执行时指定.

Answer 2

该手册页的sudo解释:

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

正如此链接所解释的那样,实现此目的的实际机制是glibc.如果UID与EUID不匹配(setuid包括任何程序的情况sudo),则删除所有"不安全的环境变量".因此,具有提升权限的程序无需更改即可运行.

Answer 3

在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登录执行

Answer 4

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