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ファイル機能（AKA Linuxの機能）をサポートしていないがと言います

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
ソース

あなたが質問をするまで、私はUnixのこの機能（ファイル機能）について聞いたこともありませんでした。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
そのカプット、今は同じページにいます。これを修正するには、> 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がそれを認識しているかどうかを確認し、ルートとして実行する必要があります。再起動が必要になる場合があります。。
% 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が競合することなくlibjli.soのバージョンが異なる独自のバージョンのJavaを持つことができるようにする方法があります。

— ams 2013

@ams：ユーザーが通常持っていない機能をユーザーに提供するプログラムを信頼しています。これは重要です。その機能を誤用しない（または他の人に誤用させない）プログラムコードを信頼しています。そのため、システム全体のレベルでこれらのライブラリを信頼する必要があります。

— ninjalj 2013年

@ams privbindユーティリティを使用すると、実行可能ベースではなく、プロセスごとにそれを実行できます。

— 2014