Come far funzionare Oracle Java 7 con setcap cap_net_bind

Sto cercando di concedere all'eseguibile Java il diritto di aprire porte inferiori a 1024 su Linux. Ecco la configurazione

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

Ecco cosa restituisce 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

Il tentativo di eseguire java genera il seguente errore.

[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

È possibile eseguire Java 7_u25 quando al binario sono stati dati privilegi elevati con setcap, in tal caso come?

JDK-6919633: Runtime non supporta POSIX capacità di file (Funzionalità del AKA Linux) dice che

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.

Come posso rendere attendibili le librerie condivise?

— ams
fonte

Fino a quando non hai posto la domanda che non ho mai nemmeno sentito parlare di questa funzione in Unix (capacità dei file). Ho trovato questo link che sembra avere la soluzione su come affidare ld.so anche alle tue librerie condivise:

JDK-7157699: impossibile eseguire java dopo aver concesso le funzionalità posix

estratto da quel post

Quando si aumentano i privilegi di un eseguibile, il caricatore di runtime (rtld), meglio conosciuto come ld.so non si collegherà con le librerie in percorsi non attendibili. Questo è il modo in cui ld.so (1) è stato progettato. Se è necessario eseguire un file eseguibile di questo tipo, è necessario aggiungere quel percorso ai percorsi attendibili di ld.so, come descritto di seguito:
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, ora siamo sulla stessa pagina, per risolvere questo problema, creare un file come> questo, con il percorso di libjli.so
% cat /etc/ld.so.conf.d/java.conf
/home/someuser/jdk1.7.0_04/jre/lib/i386/jli
Ciò aggiungerà il percorso al percorso dell'utente attendibile, che ld.so utilizzerà, per creare la sua cache di runtime, verificare se ld.so lo sta vedendo in questo modo, è necessario eseguirlo come root e potrebbe essere necessario un riavvio .
% ldconfig | grep libjli
libjli.so -> libjli.so
.......
Ora prova 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)
E il gioco è fatto.....

Riferimenti

— slm
fonte

Questo approccio sembra essere un cambiamento a livello di sistema, esiste un modo per limitare la fiducia su una base per utente in modo che l'utente foo e bar possano avere le loro diverse versioni di java con diverse versioni di libjli.so senza incorrere in conflitti.

— AMS

@ams: ti stai fidando di un programma per dare all'utente una capacità che di solito non ha. Questo è importante: ti stai fidando del codice del programma per non abusare (né permettere ad altri di abusare) di tale capacità. Ecco perché devi fidarti di quelle librerie a livello di sistema.

— ninjalj,

@ams È possibile utilizzare l' utilità privbind per poterlo fare in base al processo, non al file eseguibile.

— maggio

Come far funzionare Oracle Java 7 con setcap cap_net_bind_service + ep

Riferimenti