Я использую LD_LIBRARY_PATH, чтобы указать путь к определенной пользовательской библиотеке для приложения. Но если я устанавливаю возможности в этом приложении
sudo setcap CAP_NET_BIND_SERVICE=eip myapplication
то LD_LIBRARY_PATH, кажется, игнорируется. Когда я запускаю программу, Linux жалуется, что не может найти определенную общую библиотеку.
Я предполагаю, что существует какая-то защита, чтобы предотвратить захват приложений с расширенными правами. Есть ли способ обхода?
Да, он отключен по соображениям безопасности.
Как уже было сказано в других ответах, это поведение предназначено. Существует какое-то обходное решение, если вы можете скомпилировать (или хотя бы связать) приложение самостоятельно. Затем вы можете передать -Wl,-rpath <yourDynamicLibraryPath> в gcc или -rpath <yourDynamicLibraryPath> в ld, и вам не придется указывать LD_LIBRARY_PATH вообще при выполнении.
справочная страница для sudo объясняет:
Обратите внимание, что динамический компоновщик на большинстве операционных систем удалит переменные, которые могут управлять динамическим связыванием из среды setuid исполняемые файлы, включая sudo. В зависимости от операционной системы это может включать RLD *, DYLD *, LD_, LDR_, LIBPATH, SHLIB_PATH и другие. Эти типы переменных удаляются из среды прежде чем sudo даже начнет исполнение и, как таковой, невозможно sudo для их сохранения.
Как эта ссылка объясняет, фактический механизм для этого - в glibc. Если UID не соответствует EUID (что имеет место для любой программы setuid, включая sudo), тогда все "незащищенные переменные среды" удаляются. Таким образом, программа с повышенными привилегиями работает без изменений.
Решение этой проблемы в 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
Все вышеупомянутые операции необходимо выполнить из корневого входа
Альтернативой рассмотрению является "исправление" плохо скомпилированной общей библиотеки ELF и/или исполняемого файла с использованием patchelf для установки rpath. https://nixos.org/patchelf.html
ld.so.conf - это не всегда уверенная ставка. Он будет работать, если все, что вы выполняете, было скомпилировано должным образом. В моем случае с конкретным специально упакованным продуктом apache для поставщика он был скомпилирован настолько плохо: они даже не использовали уникальные имена файлов .so, поэтому они столкнулись с .so именами файлов из RPM в базовых репозиториях RHEL, которые предоставили некоторые довольно критически часто используемые библиотеки, Таким образом, это был единственный способ изолировать то, как они были использованы. Использование ld.so.conf для этих общих объектов в пути поставщика lib приведет к удалению большого количества материала, в том числе yum, а также сбоев общей библиотеки glibc в общесистемной области.