Ytdyklly

Background

I have written a Java program to capture network packets. The code uses a wrapper API around libpcap and works nicely - as long as I run the program via sudo.

I am now trying to figure out how to set up things so that I can run the program as a "regular" user. Ultimately, it will be run on a system where I do not have sudo privilege.

After some investigation, a possible solution has been found that involves setting capabilities that provide privileged access in a specific way. Part of this involves setting the capabilities CAP_NET_RAW and CAP_NET_ADMIN to ei (e.g. sudo setcap 'CAP_NET_RAW=ei CAP_NET_ADMIN=ei' program).

The Problem

So, I have done this for the java command on my system. Unfortunately, this has created a problem (which has been asked about by many in various forums) where when java is invoked, the following message is displayed:

java: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory

This library does indeed exist and shows up in the list of libraries for the java command.

$ sudo find / -name libjli.so -print
/opt/jdk1.7.0_79/lib/amd64/jli/libjli.so
/opt/jdk1.7.0_79/jre/lib/amd64/jli/libjli.so
/usr/java/jdk1.7.0_79/lib/amd64/jli/libjli.so
/usr/java/jdk1.7.0_79/jre/lib/amd64/jli/libjli.so
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.35.x86_64/lib/amd64/jli/libjli.so
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.35.x86_64/jre/lib/amd64/jli/libjli.so

$ which java
/usr/bin/java

$ ls -l /usr/bin/java
lrwxrwxrwx. 1 root root 22 Jun 22 2015 /usr/bin/java -> /etc/alternatives/java

$ ls -l /etc/alternatives/java
lrwxrwxrwx. 1 root root 25 Jun 22 2015 /etc/alternatives/java -> /opt/jdk1.7.0_79/bin/java

$ ls -l /opt/jdk1.7.0_79/bin/java
-rwxr-xr-x. 1 uucp 143 7718 Apr 10 2015 /opt/jdk1.7.0_79/bin/java

$ ldd /usr/bin/java
linux-vdso.so.1 => (0x00007fff3f3fa000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003150c00000)
libjli.so => /usr/java/jdk1.7.0_79/lib/amd64/jli/libjli.so (0x00007ff56d563000)
libdl.so.2 => /lib64/libdl.so.2 (0x0000003151000000)
libc.so.6 => /lib64/libc.so.6 (0x0000003150800000)
/lib64/ld-linux-x86-64.so.2 (0x0000003150400000)

BTW, I am using the Java 7 JDK, not the OpenJDK.

So, what's wrong here? Everything seems to be in place, yet it can't find what it needs. Does the fact that there are two versions of Java on the machine have anything to do it? Is there some other weird situation?

Based on my searches, this problem has been encountered by many, but I couldn't seem to find a reason, nor a solution.

Can anyone help with this?

UPDATE #1

Well, after a little more investigating, it appears that the problem is due to a "feature" in Java. The link below includes another link that gets to heart of the matter.

https://unix.stackexchange.com/a/16670/291340 with the embedded link http://blog.tinola.com/?e=7.

Based upon what I read in these, it would seem that running java with specific capabilities enabled is not allowed. Perhaps that will change at some point, with an improvement to Java security.

If anyone knows about this, or more importantly, knows that a solution has been provided, please comment.

if you are in a chroot environment you need to mount /proc to make java work.

If you use "strace" you will see something like this: readlink("/proc/self/exe", "/usr/lib/jvm/java-8-openjdk-amd6"..., 4096) That means that Java first look at "/proc/self/exe" to know where to look for /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/../lib/amd64/jli/libjli.so. So if there is no /proc it can't find libjli.so

Best regards!