我使用LD_LIBRARY_PATH为应用程序设置某个用户库的路径。但是如果我在这个应用程序上设置功能
sudo setcap CAP_NET_BIND_SERVICE=eip myapplication
然后LD_LIBRARY_PATH似乎被忽略了。当我启动程序时，Linux抱怨它无法找到某个共享库。
我认为有一些保护措施可以阻止具有扩展权限的应用程序被劫持。有解决方法吗？
答案 0 :(得分：10)
正如其他答案中所述，此行为是有意的。如果您可以自己编译（或至少链接）应用程序，则有某种解决方法。然后，您可以将-Wl,-rpath <yourDynamicLibraryPath>传递给gcc或-rpath <yourDynamicLibraryPath>到ld，执行时根本不需要指定LD_LIBRARY_PATH。
答案 1 :(得分：8)
sudo的{{3}}解释了：
请注意，大多数操作系统上的动态链接器都将删除 可以控制来自环境的动态链接的变量 setuid可执行文件，包括sudo。取决于操作系统 这可能包括 RLD *，DYLD *，LD_ ，LDR _ ，LIBPATH，SHLIB_PATH和 其他。这些类型的变量将从环境中删除 在sudo开始执行之前，因此，它是不可能的 sudo保护它们。
作为man page，执行此操作的实际机制是glibc。如果UID与EUID不匹配（任何setuid程序都是如此，包括sudo），则会删除所有“不安全的环境变量”。因此，具有提升权限的程序无需更改即可运行。
答案 2 :(得分：4)
是的，出于安全原因，它已被禁用。
答案 3 :(得分：4)
在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登录
执行答案 4 :(得分：1)
另一种考虑方法是使用patchelf“纠正”编译不良的ELF共享库和/或可执行文件来设置rpath。 https://nixos.org/patchelf.html
ld.so.conf并不总是肯定的赌注。如果你正在运行的任何东西被正确编译，它将工作。在我的情况下，对于特定的特殊打包供应商的apache产品，它编译得很糟糕：他们甚至没有使用唯一的.so文件名，因此他们与基础RHEL存储库中RPM的.so文件名冲突，提供了一些非常关键的常用库。所以这是隔离它们使用方式的唯一选择。对供应商的lib路径中的那些共享对象使用ld.so.conf会破坏很多东西，包括yum，以及系统范围内的glibc共享库故障。