Có phải PID của một tiến trình con luôn lớn hơn PID của cha mẹ trên Linux không?

Hãy nói, từ kernel 2.6 trở đi.

Tôi xem tất cả các quy trình đang chạy trên hệ thống.

Có phải PID của trẻ em luôn lớn hơn so với PID của cha mẹ chúng không?

Có thể có trường hợp đặc biệt của "đảo ngược"?

linux-kernel process

— Massimo
nguồn

Không, vì một lý do rất đơn giản là có một giá trị số tối đa mà PID có thể có. Nếu một quá trình có PID cao nhất, thì không có con nào nó có thể có một PID lớn hơn. Giải pháp thay thế cho việc cho trẻ thấp hơn sẽ là thất bại fork()hoàn toàn, điều này sẽ không hiệu quả.

Các PID được phân bổ theo thứ tự và sau khi sử dụng mức cao nhất, hệ thống sẽ kết hợp lại để sử dụng lại các mức thấp hơn (miễn phí), do đó bạn cũng có thể nhận được các mức thấp hơn cho trẻ em trong các trường hợp khác.

PID tối đa mặc định trên hệ thống của tôi ( /proc/sys/kernel/pid_max) chỉ là 32768, do đó, không khó để đạt được điều kiện xảy ra sự cố.

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

Nếu hệ thống của bạn được phân bổ ngẫu nhiên các PID ( như OpenBSD dường như làm ) thay vì liên tiếp (như Linux), sẽ có hai tùy chọn. Hoặc là sự lựa chọn ngẫu nhiên được thực hiện trên toàn bộ không gian của các PID có thể, trong trường hợp đó rõ ràng là một PID của trẻ có thể thấp hơn so với cha mẹ. Hoặc, PID con sẽ được chọn ngẫu nhiên từ các giá trị lớn hơn PID của cha mẹ, trung bình sẽ đặt nó ở giữa một nửa giữa PID của cha mẹ và tối đa. Các quy trình giả định sau đó sẽ nhanh chóng đạt đến mức tối đa và chúng ta sẽ ở cùng một điểm như đã đề cập ở trên: một ngã ba mới sẽ cần sử dụng một bộ điều khiển thấp hơn để thành công.

— ilkkachu
nguồn

FWIW, tồn tại các hệ thống trong đó các PID được phân bổ ngẫu nhiên (theo mặc định trên OpenBSD chẳng hạn) và tôi chắc chắn tôi cũng đã thấy một sơ đồ phân bổ PID tương tự trên Linux (hoặc ít nhất là đã thấy một đề xuất).

— Kusalananda

@Kusalananda, yeah, tôi nghĩ rằng cũng có một câu hỏi về điều đó trên unix.SE, quá. Tôi không có thời gian để đào nó lên, nhưng theo tôi nhớ, bản vá cho Linux đã chọn lựa ngẫu nhiên là cũ và bị bỏ rơi là không cần thiết. Mặc dù vậy, điều đó không thành vấn đề: miễn là có một mức tối đa (tương đối thấp), một khi nó được sử dụng, các lựa chọn sẽ là đưa ra mức thấp hơn hoặc giảm lỗi trên ngã ba.

— ilkkachu

unix.stackexchange.com/questions/206096/ Mạnh và unix.stackexchange.com/questions/401327/ gợi ý cho người mới bắt đầu

— Jeff Schaller

@Massimo, khía cạnh bảo mật được thảo luận trong câu hỏi này về security.se: Các bộ lọc ngẫu nhiên có mang lại nhiều bảo mật hơn không?

— ilkkachu

@RonJohn, tốt, tôi không biết giá trị của các Linux khác ở đó là gì, nhưng nó có thể sửa đổi, bạn có thể đặt nó ở mức khoảng 4 triệu (4194304 hoặc 2 ^ 22) trên các hệ thống 64 bit. (đó là một số, không phải là một lượng byte)

— ilkkachu

Ngoài ra còn tồn tại tiềm năng cho các lỗ hổng bảo mật bằng cách sử dụng thông báo kernel và tự mình tránh để phát hiện bằng cách quét bảng quy trình; điều này nếu được thực hiện đúng sẽ dẫn đến quá trình của bạn có mức độ thấp hơn và các công cụ xử lý không nhìn thấy quy trình được đề cập.

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

Procps-ng, Procps dễ bị tổn thương bởi một quá trình ẩn trong điều kiện chủng tộc. Do Proc_pid_readdir () của hạt nhân trả về các mục nhập PID theo thứ tự số tăng dần, nên một quá trình chiếm tỷ lệ cao có thể sử dụng các sự kiện inotify để xác định khi danh sách quy trình được quét và fork / exec để có được mức liệt kê thấp hơn, do đó tránh được liệt kê. Kẻ tấn công không có đặc quyền có thể che giấu một quá trình khỏi các tiện ích của Procps-ng bằng cách khai thác một điều kiện chủng tộc trong các mục đọc / Proc / PID. Lỗ hổng này ảnh hưởng đến Procps và Procps-ng cho đến phiên bản 3.3.15, các phiên bản mới hơn cũng có thể bị ảnh hưởng.

— thông qua
nguồn