Возможности Linux (setcap), похоже, отключают LD_LIBRARY_PATH

Я использую LD_LIBRARY_PATH, чтобы указать путь к определенной пользовательской библиотеке для приложения. Но если я устанавливаю возможности в этом приложении

sudo setcap CAP_NET_BIND_SERVICE=eip myapplication

то LD_LIBRARY_PATH, кажется, игнорируется. Когда я запускаю программу, Linux жалуется, что не может найти определенную общую библиотеку.

Я предполагаю, что существует какая-то защита, чтобы предотвратить захват приложений с расширенными правами. Есть ли способ обхода?

Ответы

Ответ 1

Да, он отключен по соображениям безопасности.

Ответ 2

Как уже было сказано в других ответах, это поведение предназначено. Существует какое-то обходное решение, если вы можете скомпилировать (или хотя бы связать) приложение самостоятельно. Затем вы можете передать -Wl,-rpath <yourDynamicLibraryPath> в gcc или -rpath <yourDynamicLibraryPath> в ld, и вам не придется указывать LD_LIBRARY_PATH вообще при выполнении.

Ответ 3

справочная страница для sudo объясняет:

Обратите внимание, что динамический компоновщик на большинстве операционных систем удалит переменные, которые могут управлять динамическим связыванием из среды setuid исполняемые файлы, включая sudo. В зависимости от операционной системы это может включать RLD *, DYLD *, LD_, LDR_, LIBPATH, SHLIB_PATH и другие. Эти типы переменных удаляются из среды прежде чем sudo даже начнет исполнение и, как таковой, невозможно sudo для их сохранения.

Как эта ссылка объясняет, фактический механизм для этого - в glibc. Если UID не соответствует EUID (что имеет место для любой программы setuid, включая sudo), тогда все "незащищенные переменные среды" удаляются. Таким образом, программа с повышенными привилегиями работает без изменений.

Ответ 4

Решение этой проблемы в linux выглядит следующим образом:

перейти в каталог   $cd /etc/ld.so.conf.d/ создать новый файл   $ touch xyz.conf открыть этот файл с помощью любого редактора   $vi xyz.conf

Добавьте путь вашей динамической библиотеки в этот файл по строкам, например. если ваш путь выглядит следующим образом:

/home/xyz/libs1:/home/xyz/libs2/:/home/xyz/libs3/ то в этом файле должно быть три записи: /home/xyz/libs1/ /home/xyz/libs2/ /home/xyz/libs3/

Затем сохраните этот файл и выполните следующую команду:   $ldconfig

Все вышеупомянутые операции необходимо выполнить из корневого входа

Ответ 5

Альтернативой рассмотрению является "исправление" плохо скомпилированной общей библиотеки ELF и/или исполняемого файла с использованием patchelf для установки rpath. https://nixos.org/patchelf.html

ld.so.conf - это не всегда уверенная ставка. Он будет работать, если все, что вы выполняете, было скомпилировано должным образом. В моем случае с конкретным специально упакованным продуктом apache для поставщика он был скомпилирован настолько плохо: они даже не использовали уникальные имена файлов .so, поэтому они столкнулись с .so именами файлов из RPM в базовых репозиториях RHEL, которые предоставили некоторые довольно критически часто используемые библиотеки, Таким образом, это был единственный способ изолировать то, как они были использованы. Использование ld.so.conf для этих общих объектов в пути поставщика lib приведет к удалению большого количества материала, в том числе yum, а также сбоев общей библиотеки glibc в общесистемной области.