Cara mendapatkan Oracle java 7 agar berfungsi dengan setcap cap_net_bind_service + ep


11

Saya mencoba memberikan hak eksekusi executable java untuk membuka port di bawah 1024 di Linux. Ini pengaturannya

  • /home/test/java berisi Oracle Server JRE 7.0.25
  • CentOS 6.4

Inilah pengembalian 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

Mencoba mengeksekusi java memberikan kesalahan berikut.

[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

Apakah mungkin untuk menjalankan Java 7_u25 ketika biner telah diberikan hak tinggi dengan setcap, jika demikian bagaimana?

JDK-6919633: Runtime tidak mendukung Kemampuan File POSIX (Kemampuan Linux AKA) mengatakan bahwa

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.

Bagaimana cara membuat perpustakaan bersama dipercaya?

Jawaban:


14

Sampai Anda mengajukan pertanyaan, saya bahkan belum pernah mendengar tentang fasilitas ini di Unix (kemampuan file). Saya menemukan tautan ini yang tampaknya memiliki solusi tentang bagaimana membuat ld.so mempercayai pustaka bersama Anda:

kutipan dari posting itu

Ketika seseorang meningkatkan hak akses executable, runtime loader (rtld), lebih baik dikenal sebagai ld.so tidak akan terhubung dengan perpustakaan di jalur yang tidak terpercaya. Ini adalah cara ld.so (1) dirancang. Jika seseorang perlu menjalankan executable seperti itu, maka Anda harus menambahkan jalur itu ke jalur tepercaya ld.so, yang berikut ini menjelaskan cara melakukannya:

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

Ini kaput, Ok kita berada di halaman yang sama sekarang, untuk memperbaikinya, buat file seperti> ini, dengan path ke libjli.so

% cat /etc/ld.so.conf.d/java.conf
/home/someuser/jdk1.7.0_04/jre/lib/i386/jli

Ini akan menambahkan pathname ke jalur pengguna tepercaya, yang ld.so akan gunakan, untuk membangun cache runtime-nya, verifikasi apakah ld.so melihatnya dengan melakukan ini, perlu menjalankannya sebagai root, dan reboot mungkin diperlukan .

% ldconfig | grep libjli
libjli.so -> libjli.so
.......

Sekarang uji 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)

dan begitulah .....

Referensi


1
Pendekatan ini tampaknya merupakan perubahan sistem yang luas, apakah ada cara untuk membatasi kepercayaan pada basis per pengguna sehingga pengguna foo dan bar dapat memiliki versi java yang berbeda dengan versi libjli.so yang berbeda tanpa mengalami konflik.
ams

1
@ams: Anda mempercayai sebuah program untuk memberi pengguna kemampuan yang biasanya tidak mereka miliki. Ini penting: Anda memercayai kode program untuk tidak menyalahgunakan (atau membiarkan orang lain menyalahgunakan) kemampuan itu. Itu sebabnya Anda harus mempercayai pustaka-pustaka itu pada tingkat sistem-lebar.
ninjalj

@ams Anda dapat menggunakan utilitas privbind untuk dapat melakukannya berdasarkan per proses, bukan per-eksekusi.
mighq
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.