Linux 功能 (setcap) 似乎禁用了 LD_LIBRARY_PATH
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/9843178/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Linux capabilities (setcap) seems to disable LD_LIBRARY_PATH
提问by Lorenzo Pistone
I use LD_LIBRARY_PATHto set the path of a certain user library for an application. But if I set capabilities on this application
我用来LD_LIBRARY_PATH为应用程序设置某个用户库的路径。但是如果我在这个应用程序上设置功能
sudo setcap CAP_NET_BIND_SERVICE=eip myapplication
then LD_LIBRARY_PATHseems to be ignored. When I launch the program, Linux complains that it cannot find a certain shared library.
然后LD_LIBRARY_PATH似乎被忽略了。当我启动该程序时，Linux 抱怨它找不到某个共享库。
I guess that there's some kind of protection kicking in, to prevent applications with extended rights from being hiHymaned. Is there a workaround?
我猜是有某种保护措施在起作用，以防止具有扩展权限的应用程序被劫持。有解决方法吗？
采纳答案by Lorenzo Pistone
Yes, it's disabled for security reasons.
是的，出于安全原因，它已被禁用。
回答by chrisaycock
The man pagefor sudoexplains:
该手册页的sudo解释：
Note that the dynamic linker on most operating systems will remove variables that can control dynamic linking from the environment of setuid executables, including sudo. Depending on the operating system this may include RLD*, DYLD*, LD_, LDR_, LIBPATH, SHLIB_PATH, and others. These type of variables are removed from the environment before sudo even begins execution and, as such, it is not possible for sudo to preserve them.
请注意，大多数操作系统上的动态链接器将从 setuid 可执行文件（包括 sudo）的环境中删除可以控制动态链接的变量。根据操作系统，这可能包括RLD*、DYLD*、LD_ 、LDR_、LIBPATH、SHLIB_PATH 等。在 sudo 开始执行之前，这些类型的变量已从环境中删除，因此， sudo 不可能保留它们。
As this link explains, the actual mechanism for doing this is in glibc. If the UID does not match the EUID (which is the case for any setuidprogram, including sudo), then all "unsecure environment variables" are removed. Thus, a program with elevated privileges runs without alteration.
正如此链接所解释的，执行此操作的实际机制在 glibc 中。如果 UID 与 EUID 不匹配（任何setuid程序都是这种情况，包括sudo），则删除所有“不安全的环境变量”。因此，具有提升权限的程序无需更改即可运行。
回答by scai
As already stated in other answers, this behavior is intended. There is some kind of workaround if you can compile (or at least link) the application yourself. Then you can pass -Wl,-rpath <yourDynamicLibraryPath>to gcc or -rpath <yourDynamicLibraryPath>to ld and you won't have to specify LD_LIBRARY_PATHat all on execution.
正如其他答案中已经指出的那样，这种行为是有意的。如果您可以自己编译（或至少链接）应用程序，则有某种解决方法。然后您可以传递-Wl,-rpath <yourDynamicLibraryPath>给 gcc 或-rpath <yourDynamicLibraryPath>ld 并且您根本不必LD_LIBRARY_PATH在执行时指定。
回答by user2706978
The solution to this problem on linux is as follows:
在linux上解决这个问题的方法如下：
go to directory
$cd /etc/ld.so.conf.d/create a new file
$touch xyz.conf
open this file using any editor
$vi xyz.conf
转到目录
$cd /etc/ld.so.conf.d/创建一个新文件 $touch xyz.conf 使用任何编辑器打开此文件
$vi xyz.conf
Add the your dynamic library path in this file line by line for e.g. if your path is as follows:
在此文件中逐行添加您的动态库路径，例如，如果您的路径如下：
/home/xyz/libs1:/home/xyz/libs2/:/home/xyz/libs3/then there should be three entries in this file as follows:
/home/xyz/libs1//home/xyz/libs2//home/xyz/libs3/
/home/xyz/libs1:/home/xyz/libs2/:/home/xyz/libs3/那么这个文件中应该有三个条目，如下所示：
/home/xyz/libs1//home/xyz/libs2//home/xyz/libs3/
Then save this file and execute the following command:
$ldconfig
然后保存此文件并执行以下命令：
$ldconfig
All the above mentioned operation need to be performed from root login
以上所有操作都需要从root登录进行
回答by Heather C
An alternative to consider is to "correct" a poorly compiled ELF shared library and/or executable using patchelf to set the rpath. https://nixos.org/patchelf.html
要考虑的替代方法是使用 patchelf 设置 rpath 来“纠正”编译不良的 ELF 共享库和/或可执行文件。 https://nixos.org/patchelf.html
ld.so.conf is not always the sure bet. It will work if whatever you are running was compiled properly. In my case, with a particular specially packaged vendor's apache product, it was compiled so poorly: They did not even use unique .so filenames so they conflicted with .so filenames from RPMs in the base RHEL repositories that provided some pretty critical commonly used libraries. So this was the only option to isolate how they were used. Using ld.so.conf against those shared objects in the vendor's lib path would have blown away a lot of stuff, that included yum, along with glibc shared library failures, system-wide.
ld.so.conf 并不总是确定的赌注。如果您正在运行的任何内容都被正确编译，它将起作用。在我的情况下，使用特定的特别打包供应商的 apache 产品，它的编译非常糟糕：他们甚至没有使用唯一的 .so 文件名，因此它们与来自基本 RHEL 存储库中的 RPM 的 .so 文件名冲突，后者提供了一些非常关键的常用库. 所以这是隔离它们如何使用的唯一选择。对供应商的 lib 路径中的那些共享对象使用 ld.so.conf 会吹走很多东西，包括 yum，以及系统范围内的 glibc 共享库故障。
