ओरेकल जावा 7 को सेटप कैप_नेट_बिन्द_सेवा + एप के साथ कैसे काम करें

मैं जावा निष्पादन योग्य को लिनक्स पर 1024 से नीचे खोलने का अधिकार देने की कोशिश कर रहा हूं। यहाँ सेटअप है

/home/test/java ओरेकल सर्वर JRE 7.0.25 शामिल है
सेंटोस 6.4

यहाँ क्या रिटर्न मिलता है

[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

जावा को निष्पादित करने की कोशिश करने से निम्नलिखित त्रुटि होती है।

[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

क्या जावा 7_u25 को चलाना संभव है जब बाइनरी को सेट अप के साथ उन्नत विशेषाधिकार दिए गए हैं, यदि ऐसा है तो कैसे?

JDK-6919633: रनटाइम POSIX फ़ाइल क्षमताओं का समर्थन नहीं करता है (AKA लिनक्स क्षमताओं) का कहना है कि

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.

मैं साझा पुस्तकालयों पर कैसे भरोसा करूं?

— एम्स
स्रोत

जब तक आप यह सवाल नहीं पूछते, मैंने यूनिक्स (फ़ाइल क्षमताओं) में इस सुविधा के बारे में कभी नहीं सुना। मुझे यह लिंक मिला, जिसके पास इस बात का समाधान है कि ld.so को अपने साझा पुस्तकालयों पर कैसे भरोसा करें:

JDK-7157699: सकारात्मक क्षमता प्रदान करने के बाद जावा नहीं चला सकते

उस पोस्ट के कुछ अंश

जब कोई एक निष्पादन योग्य, रनरेट लोडर (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
इसके कपूत, ठीक है अब हम एक ही पेज पर हैं, इसे ठीक करने के लिए, फ़ाइल बनाएँ जैसे> यह, 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
.......
अब जावा का परीक्षण करें:
% ./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
स्रोत

यह दृष्टिकोण एक प्रणाली में व्यापक परिवर्तन प्रतीत होता है, क्या प्रति उपयोगकर्ता के आधार पर विश्वास को प्रतिबंधित करने का एक तरीका है ताकि उपयोगकर्ता फू और बार के अपने अलग-अलग संस्करण हो सकते हैं java के विभिन्न संस्करणों के साथ libjli.so बिना किसी विरोध के चल रहा है।

— ams

@ जाम: आप उपयोगकर्ता को आमतौर पर उनके पास एक क्षमता देने के लिए एक कार्यक्रम पर भरोसा कर रहे हैं। यह महत्वपूर्ण है: आप प्रोग्राम कोड का दुरुपयोग नहीं करने के लिए (और न ही दूसरों को दुरुपयोग करने दें) पर भरोसा कर रहे हैं। यही कारण है कि आपको सिस्टम-व्यापी स्तर पर उन पुस्तकालयों पर भरोसा करना होगा।

— नंजलज

@ आप प्रति-प्रक्रिया के आधार पर, ऐसा करने में सक्षम होने के लिए निजीबाइंड उपयोगिता का उपयोग कर सकते हैं , न कि निष्पादन योग्य आधार पर।

— mighq 20