33

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

sudo setcap CAP_NET_BIND_SERVICE=eip myapplication

然后LD_LIBRARY_PATH似乎被忽略了。当我启动该程序时，Linux 抱怨它找不到某个共享库。

我猜想有某种保护措施，以防止具有扩展权限的应用程序被劫持。有解决方法吗？

4

5 回答 5

13

正如其他答案中已经说明的那样，这种行为是有意的。如果您可以自己编译（或至少链接）应用程序，则有某种解决方法。然后你可以传递-Wl,-rpath <yourDynamicLibraryPath>给 gcc 或-rpath <yourDynamicLibraryPath>ld 并且你根本不需要LD_LIBRARY_PATH在执行时指定。

于 2012-08-14T15:15:05.983 回答
11

这个问题在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登录执行

于 2014-02-28T05:42:40.270 回答
9

手册页解释：sudo

请注意，大多数操作系统上的动态链接器都会从 setuid 可执行文件（包括 sudo）的环境中删除可以控制动态链接的变量。根据操作系统，这可能包括RLD*、DYLD *、LD_ 、LDR_、LIBPATH、SHLIB_PATH 等。这些类型的变量在 sudo 开始执行之前就从环境中删除了，因此 sudo 不可能保留它们。

正如此链接所解释的，执行此操作的实际机制在 glibc 中。如果 UID 与 EUID 不匹配（任何setuid程序都是这种情况，包括sudo），则删除所有“不安全的环境变量”。因此，具有提升权限的程序无需更改即可运行。

于 2012-08-10T20:02:48.483 回答
4

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

于 2012-04-18T17:57:58.230 回答
2

要考虑的替代方法是使用 patchelf 设置 rpath 来“纠正”编译不佳的 ELF 共享库和/或可执行文件。 https://nixos.org/patchelf.html

ld.so.conf 并不总是可靠的选择。如果您正在运行的任何内容都正确编译，它将起作用。在我的例子中，对于一个特别打包的供应商的 apache 产品，它的编译非常糟糕：他们甚至没有使用唯一的 .so 文件名，因此它们与基础 RHEL 存储库中的 RPM 中的 .so 文件名冲突，这些存储库提供了一些非常关键的常用库. 因此，这是隔离它们的使用方式的唯一选择。对供应商的 lib 路径中的那些共享对象使用 ld.so.conf 会炸毁很多东西，包括 yum，以及系统范围内的 glibc 共享库故障。

于 2015-07-10T05:47:00.320 回答