Ist die PID eines untergeordneten Prozesses unter Linux immer größer als die PID seines übergeordneten Prozesses?

Sagen wir ab Kernel 2.6.

Ich beobachte alle laufenden Prozesse auf dem System.

Sind die PID der Kinder immer höher als die PID ihrer Eltern?

Ist es möglich, spezielle Fälle von "Inversion" zu haben?

linux-kernel process

— Massimo
quelle

Nein, aus dem einfachen Grund, dass es einen maximalen numerischen Wert gibt, den die PID haben kann. Wenn ein Prozess die höchste PID hat, kann kein untergeordnetes Element, das er gabelt, eine höhere PID haben. Die Alternative, dem Kind eine niedrigere PID zu geben, wäre das Versagen fork()insgesamt, was nicht sehr produktiv wäre.

Die PIDs werden der Reihe nach zugewiesen, und nachdem die höchste verwendet wurde, verwendet das System die (freien) niedrigeren PIDs erneut, sodass Sie auch in anderen Fällen niedrigere PIDs für ein Kind erhalten können.

Die voreingestellte maximale PID meines Systems ( /proc/sys/kernel/pid_max) beträgt nur 32768, daher ist es nicht schwer, den Zustand zu erreichen, in dem der Umbruch stattfindet.

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

Wenn Ihr System PIDs nach dem Zufallsprinzip ( wie es OpenBSD zu tun scheint ) anstatt nacheinander (wie bei Linux) zuweist , gibt es zwei Möglichkeiten. Entweder wurde die zufällige Auswahl über den gesamten Bereich möglicher PIDs getroffen. In diesem Fall ist es offensichtlich, dass die PID eines Kindes niedriger sein kann als die der Eltern. Oder die PID des Kindes wird zufällig aus den Werten ausgewählt, die größer sind als die PID des Elternteils, wodurch sie im Durchschnitt auf halbem Wege zwischen der PID des Elternteils und dem Maximum liegt. Das rekursive Verzweigen von Prozessen würde dann schnell das Maximum erreichen und wir wären am selben Punkt wie oben erwähnt: Eine neue Gabel müsste eine niedrigere PID verwenden, um erfolgreich zu sein.

— ilkkachu
quelle

FWIW, es gibt Systeme, bei denen die PIDs zufällig vergeben werden (standardmäßig zum Beispiel unter OpenBSD), und ich bin sicher, dass ich auch unter Linux ein ähnliches PID-Zuweisungsschema gesehen habe (oder zumindest einen Vorschlag gesehen habe).

— Kusalananda

@Kusalananda, ja, ich glaube, es gab auch eine Frage dazu unter Unix.SE. Ich habe nicht die Zeit, um es auszuwerten, aber soweit ich mich erinnere, war der Patch für Linux, für den eine zufällige PID-Auswahl vorgenommen wurde, alt und wurde als unnötig aufgegeben. Es spielt jedoch keine Rolle: Solange es eine (relativ niedrige) maximale PID gibt, können Sie nach der Verwendung entweder eine niedrigere PID angeben oder einen Fehler auf die Gabel werfen.

— Ilkkachu

unix.stackexchange.com/questions/206096/… und unix.stackexchange.com/questions/401327/… für Anfänger

— Jeff Schaller

@ Massimo, der Sicherheitsaspekt wird in dieser Frage zu security.se diskutiert: Bringen randomisierte PIDs mehr Sicherheit?

— Ilkkachu

@RonJohn, nun, ich weiß nicht, welche Werte andere Linuxes dort setzen, aber es ist änderbar, Sie können es auf 64-Bit-Systemen auf ungefähr 4 Millionen (4194304 oder 2 ^ 22) einstellen. (Es ist eine Zahl, keine Menge von Bytes)

— Ilkkachu

Es besteht auch das Potenzial für Sicherheitslücken bei der Verwendung von Kernel-Benachrichtigungen und dem Verzicht auf die Erkennung durch einen Prozess-Table-Scan. Wenn dies richtig gemacht wird, hat Ihr Prozess eine niedrigere PID und die Prozesstools sehen den fraglichen Prozess nicht.

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

procps-ng, procps ist anfällig für einen Prozess, der sich durch eine Racebedingung versteckt. Da proc_pid_readdir () des Kernels PID-Einträge in aufsteigender numerischer Reihenfolge zurückgibt, kann ein Prozess, der eine hohe PID belegt, mithilfe von Inotify-Ereignissen ermitteln, wann die Prozessliste gescannt wird, und mit fork / exec eine niedrigere PID ermitteln, wodurch eine Aufzählung vermieden wird. Ein nicht privilegierter Angreifer kann einen Prozess vor den Dienstprogrammen von procps-ng verbergen, indem er eine Racebedingung beim Lesen von / proc / PID-Einträgen ausnutzt. Diese Sicherheitsanfälligkeit betrifft procps und procps-ng bis Version 3.3.15, möglicherweise sind auch neuere Versionen betroffen.

— Thrig
quelle