Oracle Java 7을 setcap cap_net_bind_service + ep와 함께 작동시키는 방법

Linux에서 1024 미만의 포트를 열 수있는 권리를 Java 실행 파일에 부여하려고합니다. 설정은 다음과 같습니다

/home/test/java Oracle Server 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

바이너리에 setcap으로 높은 권한을 부여 받았을 때 Java 7_u25를 실행할 수 있습니까?

JDK-6919633 : 런타임 POSIX 파일 기능 (일명 리눅스 기능)를 지원하지 않습니다는 것을 말한다

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.

공유 라이브러리를 어떻게 신뢰할 수있게합니까?

— ams
소스

질문을 할 때까지 유닉스 (파일 기능) 에서이 기능에 대해 들어 본 적이 없습니다. ld.so가 공유 라이브러리를 신뢰하게 만드는 방법에 대한 해결책이있는이 링크를 찾았습니다.

JDK-7157699 : posix 기능을 부여한 후 Java를 실행할 수 없습니다

그 게시물에서 발췌

실행 파일, 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
kaput, Ok 우리는 지금 같은 페이지에 있습니다.이 문제를 해결하려면 libjli.so 경로와 함께> this와 같은 파일을 만드십시오.
% cat /etc/ld.so.conf.d/java.conf
/home/someuser/jdk1.7.0_04/jre/lib/i386/jli
이렇게하면 ld.so가 사용할 신뢰할 수있는 사용자 경로에 경로 이름을 추가하여 런타임 캐시를 빌드하고 ld.so가이를보고 경로를 확인하고 루트로 실행해야하며 재부팅해야 할 수 있습니다. .
% ldconfig | grep libjli
libjli.so -> libjli.so
.......
이제 자바 테스트 :
% ./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가 충돌하지 않고 다른 버전의 libjli.so로 자신의 다른 버전의 Java를 가질 수 있도록 사용자별로 신뢰를 제한하는 방법이 있습니까?

— ams

@ ams : 일반적으로없는 기능을 사용자에게 제공하는 프로그램을 신뢰하고 있습니다. 이것은 중요합니다. 프로그램 코드를 사용하여 해당 기능을 오용하지 않아야합니다 (다른 사람이 오용하지 않도록). 그렇기 때문에 시스템 수준에서 이러한 라이브러리를 신뢰해야합니다.

— ninjalj

@ams privbind 유틸리티를 사용하여 실행 파일이 아닌 프로세스별로 수행 할 수 있습니다.

— mighq