Issues with capabilities and OpenJDK linking

[Andrew John Hughes]

There is an issue with the linking of the libraries in the JVM due to
its use of $ORIGIN in the runtime path:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6919633

$ readelf -d /usr/lib/jvm/icedtea6/bin/java -V

Dynamic section at offset 0x9ed0 contains 31 entries:
  Tag        Type                         Name/Value
 0x00000001 (NEEDED)                     Shared library: [libz.so.1]
 0x00000001 (NEEDED)                     Shared library: [libpthread.so.0]
 0x00000001 (NEEDED)                     Shared library: [libjli.so]
 0x00000001 (NEEDED)                     Shared library: [libdl.so.2]
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]
 0x0000000e (SONAME)                     Library soname: [lib.so]
 0x0000000f (RPATH)                      Library rpath:
[$ORIGIN/../lib/ppc/jli:$ORIGIN/../jre/lib/ppc/jli]
 0x0000001d (RUNPATH)                    Library runpath:
[$ORIGIN/../lib/ppc/jli:$ORIGIN/../jre/lib/ppc/jli]

When capabilities are added to the java binary:

setcap cap_net_bind_service=+epi java

glibc no longer allows relative paths and the expansion of $ORIGIN
when the binary is run as a normal user
(http://sources.redhat.com/bugzilla/show_bug.cgi?id=11570).  So we
get:

/usr/lib/jvm/icedtea6/bin/java: error while loading shared libraries:
libjli.so: cannot open shared object file: No such file or directory

due to:

13919 open("$ORIGIN/../lib/ppc/jli/libjli.so", O_RDONLY) = -1 ENOENT
(No such file or directory)

Such a capability needs to be added to allow Java to bind ports below
1024 as an unprivileged user.

A number of possible solutions exist:

1.  Statically link java
2.  Hardcode the install path of the libraries into the runtime path
3.  Add the install path to ld.so.conf (which would require the
libraries to be properly versioned to avoid conflicts)
4.  Move the libraries onto the existing library path (again, requires
versioning)

I don't think any of these solutions are ideal.  Does anyone have any
suggestions or better solutions?

Note that this seems unrelated to the use (or not) of LD_LIBRARY_PATH
( http://blogs.sun.com/darcy/entry/purging_ld_library_path) as it
occurs in both 6 and 7.
-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8