Comment faire fonctionner Oracle Java 7 avec setcap cap_net_bind

J'essaie d'accorder à l'exécutable Java le droit d'ouvrir des ports inférieurs à 1024 sous Linux. Voici la configuration

/home/test/java contient Oracle Server JRE 7.0.25
CentOS 6.4

Voici ce que retourne 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

Essayer d'exécuter Java donne l'erreur suivante.

[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

Est-il possible d'exécuter Java 7_u25 lorsque le binaire a reçu des privilèges élevés avec setcap, si oui, comment?

JDK-6919633: Le runtime ne prend pas en charge les capacités de fichiers POSIX (AKA Linux Capabilities) indique 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.

Comment faire confiance aux bibliothèques partagées?

— ams
source

Jusqu'à ce que vous posiez la question, je n'ai même jamais entendu parler de cette fonctionnalité sous Unix (capacités de fichier). J'ai trouvé ce lien qui semble avoir la solution pour faire confiance à ld.so à vos bibliothèques partagées:

JDK-7157699: impossible d'exécuter java après l'octroi de capacités posix

extrait de ce post

Lorsque l'on augmente les privilèges d'un exécutable, le chargeur d'exécution (rtld), mieux connu car ld.so ne sera pas lié aux bibliothèques dans des chemins non approuvés. C'est ainsi que ld.so (1) a été conçu. Si vous devez exécuter un tel exécutable, vous devez ajouter ce chemin aux chemins approuvés de ld.so, ce qui suit décrit comment le faire:
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
Son kaput, Ok, nous sommes sur la même page maintenant, pour résoudre ce problème, créez un fichier tel que> this, avec le chemin d'accès à libjli.so
% cat /etc/ld.so.conf.d/java.conf
/home/someuser/jdk1.7.0_04/jre/lib/i386/jli
Cela ajoutera le chemin d'accès au chemin utilisateur de confiance, que ld.so utilisera, pour créer son cache d'exécution, vérifier si ld.so le voit en faisant cela, doit l'exécuter en tant que root, et un redémarrage peut être nécessaire .
% ldconfig | grep libjli
libjli.so -> libjli.so
.......
Maintenant, testez 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)
Et voila.....

Références

— slm
source

Cette approche semble être un changement à l'échelle du système, existe-t-il un moyen de restreindre la confiance par utilisateur afin que l'utilisateur foo et bar puissent avoir leurs propres versions différentes de java avec une version différente de libjli.so sans entrer en conflit.

— Ams

@ams: vous faites confiance à un programme pour donner à l'utilisateur une capacité qu'il n'a généralement pas. C'est important: vous faites confiance au code du programme pour ne pas abuser (ni laisser les autres abuser) de cette capacité. C'est pourquoi vous devez faire confiance à ces bibliothèques à l'échelle du système.

— ninjalj

@ams Vous pouvez utiliser l' utilitaire privbind pour pouvoir le faire par processus, et non par exécutable.

— mighq

Comment faire fonctionner Oracle Java 7 avec setcap cap_net_bind_service + ep

Références