Исключение UnsatisfiedLinkError при явном объявлении библиотеки

Попытка запустить мое приложение Java приводит к UnsatisfiedLinkError исключению, когда libmysqlclient.so.18 не может быть найден, даже если он явно объявлен в LD_LIBRARY_PATH, -Djava .library.path и /etc/ld.so.conf

ОПИСАНИЕ ПРОБЛЕМЫ

Я пытаюсь использовать pcap4j (https://github.com/kaitoy/pcap4j), оболочка Java для libpcap, поэтому я могу прослушивать пакеты NIF на моей машине из приложения Java. Поскольку libpcap требует прав суперпользователя для выполнения этой задачи, я должен каким-то образом предоставить непривилегированному пользователю, выполняющему это приложение, возможность доступа к NIF.

Сопровождающий pcap4j предлагает предоставить возможности CAP_NET_RAW и CAP_NET_ADMIN команде java следующим образом: setcap cap_net_raw,cap_net_admin=eip /path/to/java

Из-за ограничений реализации я ограничен следующим:

  • Избегайте предоставления sudo доступа непривилегированному пользователю из-за политик безопасности. То же самое рассуждение может быть применено к предоставлению вышеупомянутых возможностей команде java (не знаю, предоставляются ли права доступа для каждой пары пользователь / команда), но, исходя из моих относительно скудных знаний о безопасности, последний вариант выглядит как более ограниченное разрешение метод предоставления того, чего я хочу достичь (решения также приветствуются, если альтернативный метод предоставления разрешений выглядит более подходящим для моей цели), и, учитывая, что разработчик pcapj4, вероятно, более опытный профессионал, дает советы, поэтому я следовал пути предоставления возможности .
  • Пользователь должен иметь возможность запускать приложение без запроса пароля.
  • Предоставление разрешения должно производиться только один раз, например при первом создании пользователя.

Проблема возникла после предоставления CAP_NET_RAW и CAP_NET_ADMIN возможностей команде java. Я получаю следующее исключение при выполнении своего приложения:

Error creating entity
java.lang.UnsatisfiedLinkError: /path/to/app/lib/libxpherejava.so: libmysqlclient.so.18: cannot open shared object file: No such file or directory
        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
        at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1941)
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1857)
        at java.lang.Runtime.loadLibrary0(Runtime.java:870)
        at java.lang.System.loadLibrary(System.java:1122)

ДЕТАЛИ

JAVA: java-1.8.0-openjdk-1.8.0.171-8

ОС: Linux user-me 3.10.0-862.6.3.el7.x86_64 # 1 SMP Пт, 15 июня, 17:57:37 EDT 2018 x86_64 x86_64 x86_64 GNU / Linux [Выпуск Red Hat Enterprise Linux Server 7.5 (Майпо)]

LD_LIBRARY_PATH содержит явный путь к ненайденной библиотеке:

LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib/lwp:/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.171-8.b10.el7_5.x86_64/jre/lib/amd64/jli/libjli.so:/usr/lib64/mysql/libmysqlclient.so.18
export LD_LIBRARY_PATH

LD_LIBRARY_PATH передается в JVM с использованием java.library.path:

exec java
-XshowSettings:properties 
-Djava.library.path=${LD_LIBRARY_PATH}
-d64
...

"-XshowSettings: properties" предоставляет мне следующий вывод при выполнении java-команды:

java.library.path =
        /path/to/app/lib
        /path/to/app/lib/glib-2.0
        /usr/lib/lwp
        /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.171-8.b10.el7_5.x86_64/jre/lib/amd64/jli/libjli.so
        /usr/lib64/mysql/libmysqlclient.so.18

где /usr/lib64/mysql/libmysqlclient.so.18 - символическая ссылка на /usr/lib64/mysql/libmysqlclient.so.18.0.0

Похоже, JVM (или любой другой объект, запрашивающий доступ к libmysqlclient.so.18 из libxpherejava.so) не находит libmysqlclient.so.18 , даже если его путь явно указан в java.library.path и файл ДЕЙСТВИТЕЛЬНО существует.

Если LD_LIBRARY_PATH содержит путь к libmysqlclient.so.18 (/usr/lib64/mysql/libmysqlclient.so.18), выдача ldd libxpherejava.so приводит к тому, что libmysqlclient.so.18 не может быть найден

[user@user-me log]$ ldd /path/to/app/lib/libxpherejava.so
        linux-vdso.so.1 =>  (0x00007ffe1a73d000)
        libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007fd727df4000)
        libssl.so.10 => /lib64/libssl.so.10 (0x00007fd727b83000)
        libxphereS.so => /path/to/app/lib/libxphereS.so (0x00007fd727973000)
        libmysqlclient.so.18 => not found
        libz.so.1 => /lib64/libz.so.1 (0x00007fd72775d000)
        libnsl.so.1 => /lib64/libnsl.so.1 (0x00007fd727543000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fd727327000)
        libm.so.6 => /lib64/libm.so.6 (0x00007fd727025000)
        libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00007fd726d11000)
        libc.so.6 => /lib64/libc.so.6 (0x00007fd726944000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007fd726740000)
        libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007fd7264f3000)
        libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007fd72620b000)
        libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007fd726007000)
        libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007fd725dd4000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fd728718000)
        libpcre.so.1 => /lib64/libpcre.so.1 (0x00007fd725b72000)
        libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007fd725964000)
        libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007fd725760000)
        libresolv.so.2 => /lib64/libresolv.so.2 (0x00007fd725547000)
        libselinux.so.1 => /lib64/libselinux.so.1 (0x00007fd725320000)

Это содержимое ld.so.conf:

[user@user-me lib]$ cat /etc/ld.so.conf
/path/to/app/lib/
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.171-8.b10.el7_5.x86_64/jre/lib/amd64/jli/libjli.so
/usr/lib64/mysql/libmysqlclient.so.18

Обе библиотеки являются 64-битными:

[user@user-me lib]$ file libxpherejava.so
libxpherejava.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=82e1c673e732eb2d3770883b14facf3eff091243, not stripped
[user@user-me lib]$ file /usr/lib64/mysql/libmysqlclient.so.18
/usr/lib64/mysql/libmysqlclient.so.18: symbolic link to libmysqlclient.so.18.0.0'
[user@user-me lib]$ file /usr/lib64/mysql/libmysqlclient.so.18.0.0
/usr/lib64/mysql/libmysqlclient.so.18.0.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=79978c5f4fb259a5a146614e260ea0720dd31d3b, stripped

strace над сценарием, выполняющим команду "exec java", дает следующее -> https://dumpz.org/aGHQpNk9Znmk

СВЯЗАННЫЕ ВОПРОСЫ

Кто-нибудь знает, почему не удается найти libmysqlclient.so.18?


person null    schedule 25.01.2019    source источник
comment
Рискну предположить, что привилегированная программа проигнорирует LD_LIBRARY_PATH. (Я бы очень на это надеюсь.)   -  person roaima    schedule 26.01.2019
comment
@roaima, вы правы, man ld-linux объясняет это прямо: LD_LIBRARY_PATH <..> This variable is ignored in secure-execution mode., а в описании режима безопасного выполнения указано следующее: A binary is executed in secure-execution mode if the AT_SECURE entry in the auxiliary vector (see getauxval(3)) has a nonzero value. This entry may have a nonzero value for various reasons, including: <...> A process with a non-root user ID executed a binary that conferred capabilities to the process.   -  person Danila Kiver    schedule 26.01.2019
comment
@DanilaKiver хорошее исследование. Вы хотите написать это в качестве ответа?   -  person roaima    schedule 26.01.2019
comment
@DanilaKiver, следуя вашим рассуждениям, я передал библиотеку как -Djava.library.path = / path / to / app / lib: /usr/lib64/mysql/libmysqlclient.so.18, без использования LD_LIBRARY_PATH. Он по-прежнему не может найти библиотеку, возникает такое же исключение.   -  person null    schedule 28.01.2019
comment
@adrikayak, небольшое пояснение: Java в вашем случае явно загружает только библиотеку libxpherejava.so, вызывая функцию dlopen() изнутри (таким образом передавая управление компоновщику, ld-linux). Это единственное место, на которое влияет java.library.path (который распознается только самой Java). Проблема в том, что все зависимости загружаемой библиотеки обрабатываются компоновщиком, который ничего не знает о java.library.path - он знает только свою собственную переменную LD_LIBRARY_PATH и имеет свои собственные правила относительно нее (см. Мои предыдущие комментарии).   -  person Danila Kiver    schedule 28.01.2019
comment
@DanilaKiver Понятно. Думаю, что нашел выход: создать символическую ссылку на проблемную библиотеку libmysqlclient.so.18 в /usr/lib64. Исключения больше нет. Если больше не будет добавлено комментариев, я опубликую его как решение   -  person null    schedule 28.01.2019


Ответы (1)


Создание символической ссылки на проблемную библиотеку libmysqlclient.so.18 в /usr/lib64 решает проблему. Исключения больше нет.

person null    schedule 04.02.2019