Всегда ли PID дочернего процесса больше, чем PID его родителя в Linux?

Допустим, начиная с ядра 2.6.

Я наблюдаю за всеми запущенными процессами в системе.

Всегда ли PID детей больше, чем PID их родителей?

Возможно ли иметь особые случаи «инверсии»?

Нет, по той простой причине, что существует максимальное числовое значение, которое может иметь 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 родителя, что в среднем поместит его на полпути между PID родителя и максимумом. Процессы рекурсивного разветвления затем быстро достигнут максимума, и мы окажемся в той же точке, что и упомянутая выше: новый форк должен будет использовать более низкий PID для успеха.

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

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

procps-ng, procps уязвим для процесса, скрывающегося в состоянии гонки. Так как kernel ​​proc_pid_readdir () возвращает записи PID в порядке возрастания чисел, процесс, занимающий высокий PID, может использовать события inotify, чтобы определить, когда сканируется список процессов, и fork / exec, чтобы получить более низкий PID, таким образом избегая enums. Непривилегированный злоумышленник может скрыть процесс от утилит procps-ng, используя условие гонки при чтении записей / proc / PID. Эта уязвимость затрагивает procps и procps-ng до версии 3.3.15, также могут быть затронуты более новые версии.