JDK-7157699 : can not run java after granting posix capabilities
  • Type: Bug
  • Component: tools
  • Sub-Component: launcher
  • Affected Version: 7
  • Priority: P4
  • Status: Closed
  • Resolution: Not an Issue
  • OS: linux
  • CPU: x86
  • Submitted: 2012-03-29
  • Updated: 2012-04-04
  • Resolved: 2012-04-04
Related Reports
Relates :  
Description
FULL PRODUCT VERSION :
java version "1.7.0_02"
Java(TM) SE Runtime Environment (build 1.7.0_02-b13)
Java HotSpot(TM) 64-Bit Server VM (build 22.0-b10, mixed mode)


FULL OS VERSION :
Linux fedora 2.6.35.14-106.fc14.x86_64


A DESCRIPTION OF THE PROBLEM :
After granting the java executable cap_net_raw capabilities, java can not be executed, it reports the error:

/opt/linux-x86_64/jdk1.7.0_02//bin/java: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory

After removing the capability, it works fine.

see also 6919633


THE PROBLEM WAS REPRODUCIBLE WITH -Xint FLAG: Did not try

THE PROBLEM WAS REPRODUCIBLE WITH -server FLAG: Did not try

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
cd $JAVA_HOME/bin
sudo setcap cap_net_raw+epi ./java
./java -version

Result:
/opt/linux-x86_64/jdk1.7.0_02//bin/java: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory

EXPECTED VERSUS ACTUAL BEHAVIOR :
Expected: after setting capaility, java should run with that capability (in this case by setting cap_net_raw java program should be able to run JNI libraries that perform actions that are allowed only when cap_net_raw is granted, such as set SO_BINDTODEVICE socket option)

Actual: java fails to start, reporting
/opt/linux-x86_64/jdk1.7.0_02//bin/java: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory
ERROR MESSAGES/STACK TRACES THAT OCCUR :
/opt/linux-x86_64/jdk1.7.0_02//bin/java: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
instead of setting capability, we have to run java as root, which is not acceptable.

Comments
EVALUATION When one is raising the privileges of an executable, the runtime loader (rtld), better know as ld.so will not link with libraries in untrusted paths. This is the way the ld.so(1) has been designed. If one needs to run such an executable, then you have to add that path to the trusted paths of ld.so, the following describes how to do so: Fedora 11: % uname -a Linux localhost.localdomain 2.6.29.4-167.fc11.i686.PAE #1 SMP Wed May 27 17:28:22 EDT 2009 i686 i686 i386 GNU/Linux % sudo setcap cap_net_raw+epi ./jdk1.7.0_04/bin/java % ./jdk1.7.0_04/bin/java -version ./jdk1.7.0_04/bin/java: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory Its kaput, Ok we are on the same page now, to fix this, create a file such as this, with the path to libjli.so % cat /etc/ld.so.conf.d/java.conf /home/someuser/jdk1.7.0_04/jre/lib/i386/jli This will add the the pathname to the trusted user path, that ld.so will use, to build its runtime cache, verify if ld.so is seeing it by doing this, need to run it as root, and a reboot may be necessary. % ldconfig | grep libjli libjli.so -> libjli.so ....... Now test java: % ./jdk1.7.0_04/bin/java -version java version "1.7.0_04-ea" Java(TM) SE Runtime Environment (build 1.7.0_04-ea-b18) and there you have it..... On solaris use crle(1) or you can use useradd(1) please see, http://docs.oracle.com/cd/E19528-01/819-5899/gechg/index.html
04-04-2012

EVALUATION Likely because libjli.so was not added to the OS'es blessed library paths.
03-04-2012