Як змусити Oracle java 7 працювати з setcap cap_net_bind

Я намагаюся надати виконуваному Java-файлу право відкривати порти нижче 1024 в Linux. Ось налаштування

/home/test/java містить сервер Oracle JRE 7.0.25
CentOS 6.4

Ось що повертає 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

Спроба виконати java видає таку помилку.

[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

Чи можливо запустити Java 7_u25, коли двійковій системі надано підвищені привілеї за допомогою setcap, якщо так, як?

JDK-6919633: Час виконання не підтримує POSIX-файлові можливості (AKA Linux Capability) говорить, що

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.

Як мені зробити довіру спільних бібліотек?

— ам
джерело

Поки ви не поставили запитання, я навіть не чула про цю програму в Unix (можливості файлів). Я знайшов це посилання, яке, як видається, має рішення щодо того, як змусити ld.so довіряти вашим спільним бібліотекам:

JDK-7157699: не можна запускати Java після надання можливостей posix

уривок з цієї посади

Коли ви підвищуєте привілеї виконуваного файлу, завантажувач виконання (rtld), краще знати як ld.so, не буде зв'язуватися з бібліотеками в ненадійних шляхах. Ось так було розроблено ld.so (1). Якщо вам потрібно запустити такий виконуваний файл, вам слід додати цей шлях до довірених шляхів ld.so, нижче описано, як це зробити:
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
Його капут, Ок, ми зараз на одній сторінці, щоб виправити це, створимо такий файл, як> this, зі шляху до libjli.so
% cat /etc/ld.so.conf.d/java.conf
/home/someuser/jdk1.7.0_04/jre/lib/i386/jli
Це додасть ім'я шляху до шляху довіреного користувача, який ld.so використовуватиме, щоб створити кеш часу виконання, перевірити, чи ld.so бачить це, зробивши це, потрібно запустити його як root, і може знадобитися перезавантаження. .
% ldconfig | grep libjli
libjli.so -> libjli.so
.......
Тепер тестуємо 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)
і там у вас це є .....

Список літератури

— slm
джерело

Цей підхід, здається, є систематичним зміною, чи є спосіб обмежити довіру на основі кожного користувача, щоб користувач foo та bar міг мати власні різні версії Java з різною версією libjli.so, не впадаючи в конфлікт.

— Ams

@ams: ви довіряєте програмі, щоб надати користувачеві можливості, яких вони зазвичай не мають. Це важливо: ви довіряєте програмному коду, щоб не зловживати (і не дозволяти іншим зловживати) цією здатністю. Ось чому ви повинні довіряти цим бібліотекам на загальносистемному рівні.

— ніндзя

@ams Ви можете використовувати утиліту privbind , щоб мати змогу це робити на основі процесу, а не на виконуваній основі.

— mighq

Як змусити Oracle java 7 працювати з setcap cap_net_bind_service + ep

Список літератури