Il PID di un processo figlio è sempre maggiore del PID del suo genitore su Linux?

Diciamo, dal kernel 2.6 in poi.

Guardo tutti i processi in esecuzione sul sistema.

Il PID dei bambini è sempre maggiore dei PID dei genitori?

È possibile avere casi speciali di "inversione"?

linux-kernel process

— Massimo
fonte

Risposte:

No, per la semplice ragione che esiste un valore numerico massimo che il PID può avere. Se un processo ha il PID più alto, nessun figlio forchettato può avere un PID maggiore. L'alternativa a dare al bambino un PID inferiore sarebbe quella di fallire del fork()tutto, il che non sarebbe molto produttivo.

I PID sono assegnati in ordine e, dopo aver utilizzato quello più alto, il sistema si avvolge per riutilizzare quelli (gratuiti) inferiori, in modo da poter ottenere PID più bassi per un bambino anche in altri casi.

Il PID massimo predefinito sul mio sistema ( /proc/sys/kernel/pid_max) è solo 32768, quindi non è difficile raggiungere la condizione in cui si verifica il wraparound.

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

Se il tuo sistema dovesse allocare PID casualmente ( come sembra fare OpenBSD ) invece che consecutivamente (come Linux), ci sarebbero due opzioni. O la scelta casuale è stata fatta sull'intero spazio dei possibili PID, nel qual caso sarebbe ovvio che il PID di un bambino può essere inferiore a quello del genitore. In alternativa, il PID del bambino verrebbe scelto in modo casuale tra i valori maggiori del PID del genitore, che in media lo metterebbe a metà tra il PID del genitore e il massimo. I processi di biforcazione ricorsivamente raggiungerebbero quindi rapidamente il massimo e saremmo allo stesso punto di cui sopra: un nuovo fork avrebbe bisogno di utilizzare un PID inferiore per avere successo.

— ilkkachu
fonte

FWIW, esistono sistemi in cui i PID sono allocati casualmente (di default su OpenBSD per esempio), e sono sicuro di aver visto uno schema di allocazione PID simile anche su Linux (o almeno ne ho visto uno suggerito).

— Kusalananda

@Kusalananda, sì, penso che ci sia stata una domanda anche su unix.SE. Non ho il tempo di scavare, ma per quanto ricordo, la patch per Linux che ha fatto la scelta PID casuale era vecchia e abbandonata come superflua. Non importa però: a patto che ci sia un PID massimo (relativamente basso), una volta usato le scelte sono o di dare un PID più basso, o lasciare un errore sul fork.

— ilkkachu,

unix.stackexchange.com/questions/206096/… e unix.stackexchange.com/questions/401327/… per i principianti

— Jeff Schaller

@Massimo, l'aspetto della sicurezza è discusso in questa domanda su security.se: I PID randomizzati offrono maggiore sicurezza?

— ilkkachu,

@RonJohn, beh, non so quali valori ci mettono altri Linux, ma è modificabile, puoi impostarlo a circa 4 milioni (4194304 o 2 ^ 22) su sistemi a 64 bit. (è un numero, non una quantità di byte)

— ilkkachu,

Esiste anche il potenziale per le vulnerabilità della sicurezza che utilizzano le notifiche del kernel e si biforcano per evitare il rilevamento tramite una scansione della tabella dei processi; questo, se fatto correttamente, il tuo processo avrà un PID inferiore e gli strumenti di processo non vedono il processo in questione.

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

procps-ng, procps è vulnerabile a un processo nascosto attraverso le condizioni della razza. Poiché proc_pid_readdir () del kernel restituisce le voci PID in ordine numerico crescente, un processo che occupa un PID alto può utilizzare eventi inotify per determinare quando viene analizzato l'elenco dei processi e fork / exec per ottenere un PID inferiore, evitando così l'enumerazione. Un utente malintenzionato senza privilegi può nascondere un processo dalle utilità di procps-ng sfruttando una condizione di competizione nella lettura delle voci / proc / PID. Questa vulnerabilità interessa procps e procps-ng fino alla versione 3.3.15, anche le versioni più recenti potrebbero essere interessate.

— thrig
fonte