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

回答

相关问题