背景:
我知道出于安全原因，具有setuid的父程序无法将LD_LIBRARY_PATH保留为env的一部分，因此任何子进程也不会“看到” LD_LIBRARY_PATH。
上下文:
我的父程序(请参阅https://github.com/shadow-robot/ethercat_grant/blob/kinetic-devel/src/ethercat_grant.cpp)需要setuid才能更改子程序的功能，例如CAP_NET_RAW。但是，子程序(在我的控制下，例如https://github.com/shadow-robot/ros_ethercat/blob/kinetic-devel/ros_ethercat_loop/src/main.cpp)使用通过RPATH找到的库，它们本身需要访问依赖库，而不是在我的控制下，并且只能通过LD_LIBRARY_PATH找到(由于ubuntu仿生https://github.com/shadow-robot/ethercat_grant/issues/4中新执行的RUNPATH)。
因此，我需要一种变通方法来将LD_LIBRARY_PATH传递给子进程。
我认为 execve()应该有所帮助，而我的问题仅在这里。
解决方法:
我在父应用程序中放置了putenv()LD_LIBRARY_PATH = / my / path /，删除了特权，然后使用新的env调用execve()。我认为这是安全的，因为在环境中重新添加的LD_LIBRARY_PATH仅用作标准用户而不是特权用户。在此处查看代码https://github.com/ubi-agni/ethercat_grant/blob/env_append/src/ethercat_grant.cpp
问题: LD_LIBRARY_PATH被再次放入execve()中。
[EDIT]如果以前没有使用cap_set_file，则似乎行为正确(只要在调用execve之前就删除了特权)，所以问题在于功能和execve之间的关系[/ EDIT]
研究:我发现了一些关于该有害行为http://austingroupbugs.net/view.php?id=922的旧报告，但没有明确解释(在man ld.so或其他版本中)，即使setuid在放弃特权后与seteuid匹配(对于组相同)，execve( )将再次删除LD_LIBRARY_PATH。
问题:我想知道它仍然是这种行为，或者如果我错过了某些proc / thread功能，我也应该更改，以使子进程不会继承父“安全”执行，因此保留新的完整吗？ [EDIT]确实似乎与影响子进程的功能有关[/ EDIT]
谢谢。
最佳答案
现在，我发现问题来自功能和而不是setuid ，看来这也是本文https://stackoverflow.com/a/10215158/10801865中提到的理想行为
关于c++ - execve()的envp arg中的LD_LIBRARY_PATH被删除，即使调用setuid父级prog放弃了其特权，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/53818499/