execve（）的envp arg中的LD_LIBRARY_PATH被删除，即使调用setuid父级prog放弃了其特权

Question

背景：我了解到，出于安全原因，具有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 ，但是（在ld.so或其他人中）没有明确解释，即使setuid匹配seteuid （与组相同）删除特权后，execve（）将再次删除LD_LIBRARY_PATH。

问题：我想知道这种行为仍然是预期的，或者如果我错过了某些proc / thread功能，我也应该进行更改，以使子进程不会继承父级的“安全”执行，从而使我的新环境保持完整？ [EDIT]确实似乎与影响子进程的功能有关[/ EDIT]

谢谢。

Answer 1

现在，我发现问题出在功能而不是setuid上 ，似乎这也是本文中提到的理想行为https://stackoverflow.com/a/10215158/10801865