Ich versuche, der ausführbaren Java-Datei das Recht zu erteilen, unter Linux Ports unter 1024 zu öffnen. Hier ist die Einrichtung
/home/test/javaenthält die Oracle Server JRE 7.0.25- CentOS 6.4
Folgendes gibt getcap zurück
[[email protected] java]$ pwd
/home/test/java
[[email protected] java]$ getcap bin/java
bin/java = cap_net_bind_service+ep
[[email protected] java]$ getcap jre/bin/java
jre/bin/java = cap_net_bind_service+ep
Der Versuch, Java auszuführen, ergibt den folgenden Fehler.
[[email protected] java]$ bin/java
bin/java: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory
[[email protected] java]$ jre/bin/java
jre/bin/java: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory
Ist es möglich, Java 7_u25 auszuführen, wenn der Binärdatei erhöhte Berechtigungen mit setcap gegeben wurden, wenn ja, wie?
JDK-6919633:Runtime unterstützt keine POSIX-Dateifunktionen (A.K.A. Linux Capabilities)
sagt das
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.
Wie mache ich die gemeinsam genutzten Bibliotheken vertrauenswürdig?
Akzeptierte Antwort:
Bis Sie die Frage gestellt haben, habe ich noch nie von dieser Einrichtung in Unix (Dateifähigkeiten) gehört. Ich habe diesen Link gefunden, der die Lösung zu haben scheint, wie man ld.so dazu bringt, Ihren gemeinsam genutzten Bibliotheken zu vertrauen:
- JDK-7157699:Java kann nicht ausgeführt werden, nachdem Posix-Fähigkeiten gewährt wurden
Auszug aus diesem Beitrag
Wenn man die Privilegien einer ausführbaren Datei erhöht, wird der Laufzeitlader
(rtld), besser bekannt als ld.so, nicht mit Bibliotheken in
nicht vertrauenswürdigen Pfaden verknüpfen. Auf diese Weise wurde ld.so(1) entworfen. Wenn
solch eine ausführbare Datei ausgeführt werden muss, dann müssen Sie diesen Pfad zu
den vertrauenswürdigen Pfaden von ld.so hinzufügen, wie dies im Folgenden beschrieben wird:
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
Es ist kaput, Ok, wir sind jetzt auf der gleichen Seite, um dies zu beheben, erstellen Sie eine Datei wie> diese mit dem Pfad zu libjli.so
% cat /etc/ld.so.conf.d/java.conf
/home/someuser/jdk1.7.0_04/jre/lib/i386/jli
Dadurch wird der Pfadname zum vertrauenswürdigen Benutzerpfad hinzugefügt, den ld.so
verwenden wird, um seinen Laufzeitcache zu erstellen, zu überprüfen, ob ld.so ihn sieht, indem
dies tut, muss es als ausgeführt werden root, und ein Neustart kann erforderlich sein.
% ldconfig | grep libjli
libjli.so -> libjli.so
.......
Testen Sie jetzt 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)
und da hast du es…..
Referenzen
- POSIX-Dateifähigkeiten:Paketierung der Leistung von root
- Dies ist die häufig gestellte Frage zu den Fähigkeiten des Linux-Kernels
- Fähigkeiten-Manpage
- Fähigkeitsbasierte Sicherheit – Wikipedia
- Verwenden von Dateifunktionen anstelle von Setuid