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

Question

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

sudo setcap CAP_NET_BIND_SERVICE=eip myapplication

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

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

Answer 1

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

Answer 2

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

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

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

Answer 3

Решение этой проблемы в 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

Все вышеперечисленные операции необходимо выполнить от имени root-пользователя

Answer 4

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

Answer 5

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

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