Фон:
Я понял, что родительская программа с 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) использует библиотеки libs, найденные с помощью RPATH, которые сами нуждаются в доступе к библиотекам зависимостей, не находящимся под моим контролем и находящимся только через LD_LIBRARY_PATH (из-за недавно примененного RUNPATH в Ubuntu Bionic https://github.com/shadow-robot/ethercat_grant/issues/4).
Поэтому мне нужен обходной путь для передачи LD_LIBRARY_PATH дочернему процессу.
я думал execve () должен помочь и мой вопрос только об этом здесь.
Временное решение:
Я putenv () LD_LIBRARY_PATH = / my / path / в родительском приложении, отбрасываю привилегии, а затем вызываю execve () с новым env. Я полагаю, это безопасно, так как LD_LIBRARY_PATH, повторно добавленный в env, используется только как обычный пользователь, а не как привилегированный. Смотрите код здесь https://github.com/ubi-agni/ethercat_grant/blob/env_append/src/ethercat_grant.cpp
Проблема: LD_LIBRARY_PATH снова сбрасывается в execve ().
[EDIT] Похоже, что ведет себя правильно (если привилегированные отбрасываются перед вызовом execve), если cap_set_file раньше не использовался, поэтому проблема в том, что между возможностями и execve каким-то образом есть проблема [/ EDIT]
Исследование: Я нашел какой-то старый, все еще открытый отчет об этом нежелательном поведении http://austingroupbugs.net/view.php?id=922 , но это явно не объяснено (в man ld.so или другом), что даже если setuid соответствует seteuid (то же самое для групп) после удаления привилегий, execve () снова удалит LD_LIBRARY_PATH.
Вопрос: Я хотел бы знать, что это поведение все еще предназначено, или если я пропустил некоторые возможности proc / thread, я должен также изменить, чтобы дочерний процесс не наследовал родительское «безопасное» выполнение, и, следовательно, оставил мой новый env без изменений? [EDIT] Это действительно, кажется, связано с возможностями, влияющими на процесс ребенка [/ EDIT]
Благодарю.
Теперь, когда я обнаружил, что проблема исходит от возможности а также не из setuid, кажется, это также желаемое поведение, как упомянуто в этом посте https://stackoverflow.com/a/10215158/10801865
Других решений пока нет …