Linux - Comment faire fonctionner Oracle Java 7 avec Setcap Cap_net_bind_service+ep ?

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 le serveur Oracle JRE 7.0.25
• CentOS 6.4

Voici ce que getcap renvoie

[[email protected] java]$ pwd
/home/test/java

[[email protected] java]$ getcap bin/java
bin/java = cap_net_bind_service+ep

[[email protected] java]$ getcap jre/bin/java
jre/bin/java = cap_net_bind_service+ep

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

[[email protected] java]$ bin/java
bin/java: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory
[[email protected] 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 :Runtime ne prend pas en charge les capacités de fichiers POSIX (A.K.A. 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 rendre les bibliothèques partagées fiables ?

Réponse acceptée :

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

• JDK-7157699 :impossible d'exécuter java après avoir accordé les capacités posix

extrait de ce message

Lorsque l'on élève les privilèges d'un exécutable, le chargeur d'exécution
(rtld), mieux connu sous le nom de ld.so ne sera pas lié aux bibliothèques dans
des chemins non fiables. C'est ainsi que le ld.so(1) a été conçu. Si
on a besoin d'exécuter un tel exécutable, alors vous devez ajouter ce chemin aux
chemins de confiance de ld.so, ce qui suit décrit comment 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

C'est kaput, Ok nous sommes sur la même page maintenant, pour résoudre ce problème, créez un fichier tel que> celui-ci, avec le chemin vers 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 d'accès de l'utilisateur de confiance, que ld.so
utilisera, pour construire son cache d'exécution, vérifier si ld.so le voit en
faisant cela, besoin de 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 voilà…..

Références

• Fonctionnalités des fichiers POSIX :optimiser la puissance de root
• Ceci est la FAQ sur les capacités du noyau Linux
• page de manuel des fonctionnalités
• Sécurité basée sur les capacités – wikipedia
• Utilisation des fonctionnalités de fichier au lieu de Setuid

En relation :Linux – Comment créer /dev/null ?