Le PID d'un processus enfant est-il toujours supérieur au PID de son parent sous Linux?

Disons, à partir du noyau 2.6.

Je regarde tous les processus en cours d'exécution sur le système.

Le PID des enfants est-il toujours supérieur au PID de leurs parents?

Est-il possible d'avoir des cas particuliers "d'inversion"?

linux-kernel process

— Massimo
source

Non, pour la raison très simple qu'il existe une valeur numérique maximale que le PID peut avoir. Si un processus a le PID le plus élevé, aucun enfant qu'il forche ne peut avoir un PID supérieur. L'alternative à donner à l'enfant un PID inférieur serait d'échouer fork()complètement, ce qui ne serait pas très productif.

Les PID sont alloués dans l'ordre, et après que le plus élevé soit utilisé, le système se contente de réutiliser les PID inférieurs (gratuits), de sorte que vous pouvez également obtenir des PID inférieurs pour un enfant dans d'autres cas.

Le PID maximum par défaut sur mon système ( /proc/sys/kernel/pid_max) n'est que de 32 768, il n'est donc pas difficile d'atteindre la condition dans laquelle le bouclage se produit.

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

Si votre système devait allouer des PID de manière aléatoire ( comme OpenBSD semble le faire ) plutôt que consécutivement (comme Linux), il y aurait deux options. Soit le choix aléatoire a été fait sur tout l'espace des PID possibles, auquel cas il serait évident que le PID d'un enfant peut être inférieur à celui du parent. Ou, le PID de l'enfant serait choisi au hasard parmi les valeurs supérieures au PID du parent, ce qui le mettrait en moyenne à mi-chemin entre le PID du parent et le maximum. Les processus bifurquant récursivement atteindraient alors rapidement le maximum et nous serions au même point que mentionné ci-dessus: un nouveau fork devrait utiliser un PID inférieur pour réussir.

— ilkkachu
source

FWIW, il existe des systèmes où les PID sont alloués de manière aléatoire (par défaut sur OpenBSD par exemple), et je suis sûr que j'ai également vu un schéma d'allocation de PID similaire sur Linux (ou du moins vu celui suggéré).

— Kusalananda

@Kusalananda, oui, je pense qu'il y a aussi eu une question à ce sujet sur unix.SE. Je n'ai pas le temps de le creuser, mais pour autant que je m'en souvienne, le correctif pour Linux qui faisait un choix PID aléatoire était ancien et abandonné car inutile. Cela n'a pas d'importance cependant: tant qu'il y a un PID maximum (relativement bas), une fois qu'il est utilisé, les choix sont soit de donner un PID inférieur, soit de supprimer une erreur sur la fourche.

— ilkkachu

unix.stackexchange.com/questions/206096/… et unix.stackexchange.com/questions/401327/… pour les débutants

— Jeff Schaller

@Massimo, l'aspect sécurité est abordé dans cette question sur security.se: les PID randomisés apportent-ils plus de sécurité?

— ilkkachu

@RonJohn, eh bien, je ne sais pas quelles valeurs les autres Linux y mettent, mais il est modifiable, vous pouvez le définir à environ 4 millions (4194304 ou 2 ^ 22) sur les systèmes 64 bits. (c'est un nombre, pas un nombre d'octets)

— ilkkachu

Il existe également un risque de vulnérabilités de sécurité en utilisant les notifications du noyau et en vous forçant à éviter d'être détecté par une analyse de la table des processus; si cela est fait correctement, votre processus aura un PID inférieur et les outils de processus ne verront pas le processus en question.

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

procps-ng, procps est vulnérable à un processus se cachant par condition de concurrence. Étant donné que proc_pid_readdir () du noyau renvoie les entrées PID dans un ordre numérique croissant, un processus occupant un PID élevé peut utiliser des événements inotify pour déterminer quand la liste des processus est analysée, et fork / exec pour obtenir un PID inférieur, évitant ainsi l'énumération. Un attaquant non privilégié peut masquer un processus aux utilitaires de procps-ng en exploitant une condition de concurrence critique dans la lecture des entrées / proc / PID. Cette vulnérabilité affecte procps et procps-ng jusqu'à la version 3.3.15, les versions plus récentes peuvent également être affectées.

— branler
source