【问题标题】:UnsatisfiedLinkError exception when lib is explicitly declared显式声明 lib 时出现 UnsatisfiedLinkError 异常
【发布时间】:2019-01-25 14:44:33
【问题描述】:

libmysqlclient.so.18 无法找到时,即使在 LD_LIBRARY_PATH 中明确声明,尝试执行我的 Java 应用程序也会产生 UnsatisfiedLinkError 异常, -Djava.library.path/etc/ld.so.conf

问题描述

我正在尝试使用 pcap4j (https://github.com/kaitoy/pcap4j),它是 libpcap 的 Java 包装器,因此我可以从 Java 应用程序中嗅探我机器 NIF 上的数据包。 由于 libpcap 需要超级用户权限才能执行此任务,我必须以某种方式赋予执行此应用程序的非特权用户访问 NIF 的能力。

pcap4j 的维护者建议为 java 命令授予功能CAP_NET_RAWCAP_NET_ADMIN,如下所示: setcap cap_net_raw,cap_net_admin=eip /path/to/java

由于实施限制,我受到以下限制:

  • 由于安全策略,避免向非特权用户授予 sudo 访问权限。相同的推理可以应用于上述授予 提到java命令的功能(不知道是否 每个用户/命令对都授予功能),但是,从我的 关于安全性的知识相对稀缺,后一种选择看起来 就像我想要的更划定的权限授予方法 实现(如果有替代许可,也欢迎解决方案 授予方法看起来更适合我的目的),并且鉴于 pcapj4 开发人员,可能更有经验的专业人士,建议 所以,我遵循了能力授予路径。
  • 用户必须能够在没有密码提示的情况下执行应用程序
  • 权限授予只能执行一次,例如首次创建用户时。

CAP_NET_RAWCAP_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 Fri Jun 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 通过使用 java.library.path 传递给 JVM:

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(或任何从 libxpherejava.so 请求访问 libmysqlclient.so.18 的实体)找不到 libmysqlclient.so.18,即使它的路径明确提供给 java.library.path 和文件确实存在。

如果 LD_LIBRARY_PATH 包含 libmysqlclient.so.18 (/usr/lib64/mysql/libmysqlclient.so.18) 的路径,发出 ldd of 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

执行“exec java”命令的脚本上的 strace 会产生这个 --> https://dumpz.org/aGHQpNk9Znmk

相关问题

有谁知道为什么找不到libmysqlclient.so.18

【问题讨论】:

  • 我会冒险猜测特权程序会忽略LD_LIBRARY_PATH。 (我当然希望它会。)
  • @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.
  • @DanilaKiver 很好的研究。你想把它写下来作为答案吗?
  • @DanilaKiver 按照您的推理,我已将库作为 -Djava.library.path=/path/to/app/lib:/usr/lib64/mysql/libmysqlclient.so.18 传递,没有使用 LD_LIBRARY_PATH。它仍然无法找到库,出现同样的异常。
  • @adrikayak,稍微澄清一下:在您的情况下,Java 通过在内部调用 dlopen() 函数显式地仅加载 libxpherejava.so 库(从而将控制权传递给链接器,ld-linux)。这是这里唯一受java.library.path 影响的地方(仅被Java 本身识别)。问题是正在加载的库的所有依赖项都由链接器处理,它对java.library.path 一无所知-它只知道自己的LD_LIBRARY_PATH 变量并且有自己的规则(参见我以前的cmets) .

标签: rhel java shared-libraries


【解决方案1】:

/usr/lib64 下创建指向有问题库libmysqlclient.so.18 的符号链接可以解决问题。异常消失了。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2022-01-02
    相关资源
    最近更新 更多