Чи ПІД дочірнього процесу завжди більший, ніж ПІД його батька в Linux?

Скажімо, від ядра 2.6 далі.

Я спостерігаю за усіма запущеними процесами в системі.

Чи ПІД дітей завжди більший за ПІД батьків?

Чи можливі особливі випадки "інверсії"?

linux-kernel process

Ні, з дуже простої причини, що існує максимальне числове значення, яке може мати PID. Якщо процес має найвищий PID, жоден дочірній він не може мати більший PID. Альтернативою, щоб дати дитині менший PID, було б fork()взагалі провалити , що було б не дуже продуктивно.

PID-адреси розподіляються в порядку, і після використання найвищого, система завертається для повторного використання (вільних) нижчих, тому ви можете отримати нижчі PID-адреси для дитини і в інших випадках.

Максимальний PID у моїй системі ( /proc/sys/kernel/pid_max) становить всього 32768, тому не важко досягти умови, коли відбувається обертання.

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

Якщо ваша система повинна була розподіляти PID випадковим чином ( як, здається, OpenBSD ) замість послідовно (як Linux), було б два варіанти. Або випадковий вибір був зроблений у всьому просторі можливих ПІД, і в цьому випадку очевидно, що ПІД дитини може бути нижчим, ніж у батьків. Або PID дитини вибирався б випадковим чином із значень, більших за PID батьків, які в середньому ставлять його на половину між PID батьків та максимальним. Рекурсивно розгортання процесів швидко досягає максимуму, і ми опинимося в тій же самій точці, про яку було сказано вище: для досягнення успіху новій вилці потрібно використовувати нижчий PID.

— ілкака
джерело

FWIW, є системи, де PID розподіляються випадковим чином (наприклад, за замовчуванням у OpenBSD, наприклад), і я впевнений, що я бачив подібну схему розподілу PID в Linux (або принаймні бачив одну запропоновану).

— Кусалаланда

@Kusalananda, так, я думаю, що питання про це було і на unix.SE. У мене немає часу розкопати це, але, наскільки я пам’ятаю, патч для Linux, який робив випадковий вибір PID, був старим і покинутий як непотрібний. Не важливо, хоча: поки існує (відносно низький) максимальний PID, після його вибору вибір або дає нижчий PID, або помилка на вилці.

— ilkkachu

unix.stackexchange.com/questions/206096/… та unix.stackexchange.com/questions/401327/… для початківців

— Jeff Schaller

@Massimo, аспект безпеки обговорюється в цьому питанні на security.se: Чи рандомізовані PID приносять більшу безпеку?

— ilkkachu

@RonJohn, ну, я не знаю, які значення там вкладають інші Linuxes, але це можна змінити, ви можете встановити його приблизно в 4 мільйони (4194304 або 2 ^ 22) у 64-бітних системах. (це число, а не кількість байтів)

— ilkkachu

Також існує потенціал вразливості безпеки, використовуючи сповіщення ядра та змушуючи себе уникати виявлення методом сканування таблиці процесів; це, якщо правильно виконано, призводить до того, що ваш процес має менший PID та інструменти обробки, не бачачи процес, про який йде мова.

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

procps-ng, propps є вразливим до процесу, що переховується через перегони. Оскільки proc_pid_readdir () ядра повертає записи PID у порядку зростання чисел, процес, що займає високий PID, може використовувати ініціативні події, щоб визначити, коли список процесів сканується, і fork / exec для отримання нижчого PID, таким чином уникаючи перерахування. Непривілейований зловмисник може приховати процес від утиліти propps-ng, використовуючи перегоновий стан під час читання / proc / PID-записів. Ця вразливість впливає на propps і propps-ng до версії 3.3.15, також можуть впливати новіші версії.

— тріг
джерело