O PID de um processo filho é sempre maior que o PID de seu pai no Linux?

Question

Vamos dizer, do kernel 2.6 em diante.

Eu assisto todos os processos em execução no sistema.

O PID das crianças é sempre maior que os PIDs dos pais?

É possível ter casos especiais de "inversão"?

    

Answer 1

Não, pela simples razão de que existe um valor numérico máximo que o PID pode ter. Se um processo tiver o PID mais alto, nenhum filho poderá ter um PID maior. A alternativa para dar à criança um menor PID seria falhar o fork() , o que não seria muito produtivo.

Os PIDs são alocados em ordem, e depois que o mais alto é usado, o sistema volta a reutilizar os menores (livres), para que você possa obter PIDs mais baixos para uma criança em outros casos também.

O PID máximo padrão no meu sistema ( /proc/sys/kernel/pid_max ) é apenas 32768, portanto, não é difícil alcançar a condição em que ocorre a mudança.

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

Se o seu sistema fosse alocar aleatoriamente PIDs ( como o OpenBSD parece fazer ) em vez de consecutivamente (como o Linux ), haveria duas opções. A escolha aleatória foi feita em todo o espaço de possíveis IDPs, caso em que seria óbvio que o IDP de uma criança pode ser menor que o da mãe. Ou, o PID da criança seria escolhido aleatoriamente a partir dos valores maiores do que o PID do pai, o que, em média, o colocaria entre o PID do pai e o máximo. Os processos de bifurcação recursiva alcançariam rapidamente o máximo e estaríamos no mesmo ponto mencionado acima: uma nova bifurcação precisaria usar um PID menor para ter sucesso.

    

Answer 2

Existe também o potencial para vulnerabilidades de segurança usando notificações do kernel e se forçando a evitar a detecção por uma varredura de tabela de processos; isso se feito corretamente resulta em seu processo tendo um PID inferior e ferramentas de processo não vendo o processo em questão.

link

procps-ng, procps is vulnerable to a process hiding through race condition. Since the kernel's proc_pid_readdir() returns PID entries in ascending numeric order, a process occupying a high PID can use inotify events to determine when the process list is being scanned, and fork/exec to obtain a lower PID, thus avoiding enumeration. An unprivileged attacker can hide a process from procps-ng's utilities by exploiting a race condition in reading /proc/PID entries. This vulnerability affects procps and procps-ng up to version 3.3.15, newer versions might be affected also.