Cómo hacer que Oracle java 7 funcione con setcap cap_net_bind

Estoy tratando de otorgar al ejecutable de Java el derecho de abrir puertos por debajo de 1024 en Linux. Aquí está la configuración

/home/test/java contiene el servidor Oracle JRE 7.0.25
CentOS 6.4

Esto es lo que devuelve getcap

[test@centos6 java]$ pwd
/home/test/java

[test@centos6 java]$ getcap bin/java
bin/java = cap_net_bind_service+ep

[test@centos6 java]$ getcap jre/bin/java
jre/bin/java = cap_net_bind_service+ep

Intentar ejecutar java da el siguiente error.

[test@centos6 java]$ bin/java
bin/java: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory
[test@centos6 java]$ jre/bin/java
jre/bin/java: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory

¿Es posible ejecutar Java 7_u25 cuando el binario ha recibido privilegios elevados con setcap, si es así, cómo?

JDK-6919633: Runtime no es compatible con las capacidades de archivo POSIX (AKA Linux Capabilities) dice que

Note: when using the setcap the libraries needed by the java launcher
should be present in /usr/lib or any other "trusted" location that the
runtime loader (rtld) uses to find shared libraries.

¿Cómo hago que las bibliotecas compartidas sean confiables?

— ams
fuente

Hasta que hizo la pregunta, nunca escuché de esta instalación en Unix (capacidades de archivo). Encontré este enlace que parece tener la solución sobre cómo hacer que ld.so confíe en sus bibliotecas compartidas:

JDK-7157699: no se puede ejecutar java después de otorgar capacidades posix

extracto de esa publicación

Cuando se aumentan los privilegios de un ejecutable, el cargador de tiempo de ejecución (rtld), mejor conocido como ld.so no se vinculará con bibliotecas en rutas no confiables. Esta es la forma en que se ha diseñado ld.so (1). Si necesita ejecutar un ejecutable de este tipo, debe agregar esa ruta a las rutas confiables de ld.so, a continuación se describe cómo hacerlo:
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
Es kaput, Ok, ahora estamos en la misma página, para solucionar esto, cree un archivo como> this, con la ruta a libjli.so
% cat /etc/ld.so.conf.d/java.conf
/home/someuser/jdk1.7.0_04/jre/lib/i386/jli
Esto agregará el nombre de ruta a la ruta de usuario de confianza, que ld.so usará, para construir su caché de tiempo de ejecución, verificar si ld.so lo está viendo al hacer esto, necesita ejecutarlo como root, y puede ser necesario reiniciar .
% ldconfig | grep libjli
libjli.so -> libjli.so
.......
Ahora prueba 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)
Y ahí lo tienes.....

Referencias

— slm
fuente

Este enfoque parece ser un cambio en todo el sistema, ¿hay alguna forma de restringir la confianza por usuario para que el usuario foo y bar puedan tener sus propias versiones diferentes de java con diferentes versiones de libjli.so sin entrar en conflicto?

— enms.

@ams: confía en un programa para darle al usuario una capacidad que generalmente no tiene. Esto es importante: confía en el código del programa para no hacer mal uso (ni dejar que otros hagan mal uso) de esa capacidad. Es por eso que debe confiar en esas bibliotecas a nivel de todo el sistema.

— ninjalj

@ams Puede usar la utilidad privbind para poder hacerlo por proceso, no por ejecutable.

— mighq

Cómo hacer que Oracle java 7 funcione con setcap cap_net_bind_service + ep

Referencias