Jak zmusić Oracle Java 7 do pracy z setcap cap_net_bind

Usiłuję przyznać plikowi wykonywalnemu Java prawo do otwierania portów poniżej 1024 w systemie Linux. Oto konfiguracja

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

Oto, co zwraca 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

Próba wykonania java powoduje następujący błąd.

[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

Czy można uruchomić Javę 7_u25, gdy plik binarny ma podwyższone uprawnienia z setcap, jeśli tak, to w jaki sposób?

JDK-6919633: Środowisko wykonawcze nie obsługuje funkcji plików POSIX (AKA Linux Capabilities) mówi, że

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.

Jak uczynić biblioteki współdzielone zaufanymi?

— ams
źródło

Dopóki nie zadałeś pytania, nigdy nie słyszałem o tej funkcji w Uniksie (możliwości plików). Znalazłem ten link, który wydaje się mieć rozwiązanie, jak sprawić, by ld.so ufał twoim bibliotekom współdzielonym:

JDK-7157699: nie można uruchomić Java po przyznaniu możliwości POSIX

fragment tego postu

Gdy ktoś podnosi uprawnienia do pliku wykonywalnego, moduł ładujący (rtld), lepiej znany jako ld.so, nie będzie łączył się z bibliotekami w niezaufanych ścieżkach. Tak właśnie zaprojektowano ld.so (1). Jeśli trzeba uruchomić taki plik wykonywalny, musisz dodać tę ścieżkę do zaufanych ścieżek pliku ld.so, poniżej opisano, jak to zrobić:
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
Jego kaput, Ok jesteśmy teraz na tej samej stronie, aby to naprawić, utwórz plik taki jak> ten, ze ścieżką do libjli.so
% cat /etc/ld.so.conf.d/java.conf
/home/someuser/jdk1.7.0_04/jre/lib/i386/jli
Spowoduje to dodanie nazwy ścieżki do ścieżki zaufanego użytkownika, której będzie używać ld.so, w celu zbudowania pamięci podręcznej środowiska uruchomieniowego, sprawdzenia, czy ld.so widzi to przez to, należy uruchomić ją jako root, i może być konieczne ponowne uruchomienie .
% ldconfig | grep libjli
libjli.so -> libjli.so
.......
Teraz przetestuj 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)
i masz to .....

Bibliografia

— slm
źródło

To podejście wydaje się być zmianą ogólnosystemową, czy istnieje sposób na ograniczenie zaufania dla poszczególnych użytkowników, aby użytkownik foo i bar mógł mieć swoje własne wersje java z inną wersją libjli.so bez wpadania w konflikt.

— AMS

@ams: ufasz programowi, który da użytkownikowi możliwości, których zwykle nie mają. Jest to ważne: ufasz kodowi programu, aby nie nadużywać (ani nie dopuszczać do innych nadużyć) tej możliwości. Dlatego musisz ufać tym bibliotekom na poziomie całego systemu.

— ninjalj

@ams Możesz użyć narzędzia privbind , aby móc to zrobić dla poszczególnych procesów, a nie dla plików wykonywalnych.

— mighq

Jak zmusić Oracle Java 7 do pracy z setcap cap_net_bind_service + ep

Bibliografia