Apakah PID suatu proses anak selalu lebih besar daripada PID induknya di Linux?


22

Katakanlah, dari kernel 2.6 dan seterusnya.

Saya menonton semua proses yang berjalan pada sistem.

Apakah PID anak-anak selalu lebih besar daripada PID orang tua mereka?

Apakah mungkin untuk memiliki kasus "inversi" khusus?

Jawaban:


47

Tidak, untuk alasan yang sangat sederhana bahwa ada nilai numerik maksimum yang dapat dimiliki PID. Jika suatu proses memiliki PID tertinggi, tidak ada anak yang bercabang dapat memiliki PID yang lebih besar. Alternatif untuk memberi anak PID lebih rendah adalah dengan gagal total fork(), yang tidak akan sangat produktif.

PID dialokasikan secara berurutan, dan setelah yang tertinggi digunakan, sistem membungkus untuk menggunakan kembali yang (gratis) lebih rendah, sehingga Anda bisa mendapatkan PID yang lebih rendah untuk anak dalam kasus lain juga.

PID maksimum default di sistem saya ( /proc/sys/kernel/pid_max) hanya 32768, jadi tidak sulit untuk mencapai kondisi di mana sampulnya terjadi.

$ echo $$
27468
$ bash -c 'echo $$'
1296
$ bash -c 'echo $$'
1297

Jika sistem Anda mengalokasikan PID secara acak ( seperti yang dilakukan OpenBSD ) alih-alih secara berurutan (seperti Linux), akan ada dua opsi. Entah pilihan acak dibuat atas seluruh ruang PID yang mungkin, dalam hal ini jelas bahwa PID anak bisa lebih rendah daripada orang tua. Atau, PID anak akan dipilih secara acak dari nilai-nilai yang lebih besar dari PID induknya, yang rata-rata akan menempatkannya di tengah-tengah antara PID induk dan maksimum. Proses bercabang secara rekursif akan dengan cepat mencapai maksimum dan kita akan berada pada titik yang sama seperti yang disebutkan di atas: garpu baru perlu menggunakan PID yang lebih rendah untuk berhasil.


3
FWIW, ada sistem di mana PID dialokasikan secara acak (secara default pada OpenBSD misalnya), dan saya yakin saya telah melihat skema alokasi PID yang serupa di Linux juga (atau setidaknya melihat yang disarankan).
Kusalananda

@ Kusalananda, ya, saya pikir sudah ada pertanyaan tentang itu di unix.SE juga. Saya tidak punya waktu untuk menggali, tetapi sejauh yang saya ingat, tambalan untuk Linux yang melakukan pemilihan PID acak sudah tua dan ditinggalkan sebagai hal yang tidak perlu. Tidak masalah: selama ada PID maksimum (relatif rendah), setelah digunakan pilihannya adalah memberikan PID yang lebih rendah, atau menjatuhkan kesalahan pada garpu.
ilkkachu


2
@ Massimo, aspek keamanan dibahas dalam pertanyaan ini pada security.se: Apakah PID acak membawa lebih banyak keamanan?
ilkkachu

1
@RonJohn, well, saya tidak menghargai nilai yang diberikan Linux lain, tetapi ini dapat dimodifikasi, Anda dapat mengaturnya menjadi sekitar 4 juta (4194304, atau 2 ^ 22) pada sistem 64-bit. (itu angka, bukan jumlah byte)
ilkkachu

8

Juga terdapat potensi kerentanan keamanan menggunakan pemberitahuan kernel dan memalsukan diri Anda untuk menghindari deteksi dengan pemindaian tabel proses; ini jika dilakukan dengan benar menghasilkan proses Anda memiliki PID yang lebih rendah dan alat proses yang tidak melihat proses tersebut.

http://cve.circl.lu/cve/CVE-2018-1121

procps-ng, procps rentan terhadap proses persembunyian melalui kondisi ras. Karena proc_pid_readdir () mengembalikan entri PID dalam urutan numerik yang menaik, suatu proses yang menempati PID tinggi dapat menggunakan peristiwa inotify untuk menentukan kapan daftar proses sedang dipindai, dan bercabang-cabang untuk mendapatkan PID yang lebih rendah, sehingga menghindari enumerasi. Penyerang yang tidak memiliki hak pribadi dapat menyembunyikan proses dari utilitas procps-ng dengan mengeksploitasi kondisi ras dalam entri pembacaan / proc / PID. Kerentanan ini memengaruhi procps dan procps-ng hingga versi 3.3.15, versi yang lebih baru mungkin akan terpengaruh juga.

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.