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

Digamos, a partir do kernel 2.6 em diante.

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

O IDP dos filhos é sempre maior que o ID dos pais?

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

linux-kernel process

— Massimo
fonte

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 que ele bifurque poderá ter um PID maior. A alternativa para dar à criança um IDP menor seria falhar fork()completamente, o que não seria muito produtivo.

Os PIDs são alocados em ordem e, depois que o mais alto é usado, o sistema se reutiliza para reutilizar os mais baixos (gratuitos), 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 a envolvente acontece.

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

Se seu sistema alocasse PIDs aleatoriamente ( 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 a ID da criança pode ser menor que a dos pais. Ou, o PID da criança seria escolhido aleatoriamente entre os valores maiores que o PID do pai, o que, em média, o colocaria no meio do caminho 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 mais baixo para ter sucesso.

— ilkkachu
fonte

FWIW, existem sistemas em que os PIDs são alocados aleatoriamente (por padrão no OpenBSD, por exemplo), e tenho certeza de que também vi um esquema de alocação de PID semelhante no Linux (ou pelo menos vi um sugerido).

— Kusalananda

@ Kusalananda, sim, acho que houve uma pergunta sobre isso no unix.SE também. Não tenho tempo para desenterrá-lo, mas, tanto quanto me lembro, o patch para Linux que fazia a escolha aleatória de PID era antigo e abandonado como desnecessário. No entanto, não importa: desde que haja um PID máximo (relativamente baixo), uma vez usada, as opções são fornecer um PID mais baixo ou soltar um erro no garfo.

— Ilkkachu # 4/18

unix.stackexchange.com/questions/206096/… e unix.stackexchange.com/questions/401327/… para iniciantes

— Jeff Schaller

@ Massimo, o aspecto de segurança é discutido nesta pergunta em security.se: Os PIDs aleatórios trazem mais segurança?

— ilkkachu

@ RonJohn, não sei o que os outros Linux colocam lá, mas é modificável, você pode configurá-lo para cerca de 4 milhões (4194304 ou 2 ^ 22) em sistemas de 64 bits. (é um número, não uma quantidade de bytes)

— ilkkachu

Também existe o potencial de vulnerabilidades de segurança usando notificações do kernel e se bifurcando para evitar a detecção por uma verificação da tabela de processos; isso se feito corretamente resulta em um processo com um PID mais baixo e ferramentas de processo que não veem o processo em questão.

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

procps-ng, procps é vulnerável a um processo oculto pela condição de corrida. Como proc_pid_readdir () do kernel retorna entradas PID em ordem numérica crescente, um processo que ocupa um PID alto pode usar eventos inotify para determinar quando a lista de processos está sendo varrida, e fork / exec para obter um PID mais baixo, evitando assim a enumeração. Um invasor sem privilégios pode ocultar um processo dos utilitários do procps-ng, explorando uma condição de corrida nas entradas de leitura / proc / PID. Essa vulnerabilidade afeta os processos e processos até a versão 3.3.15. As versões mais recentes também podem ser afetadas.

— agitar
fonte