¿El PID de un proceso hijo siempre es mayor que el PID de su padre en Linux?

Digamos, desde el kernel 2.6 en adelante.

Miro todos los procesos en ejecución en el sistema.

¿Los PID de los niños son siempre mayores que los PID de sus padres?

¿Es posible tener casos especiales de "inversión"?

linux-kernel process

— Massimo
fuente

Respuestas:

No, por la sencilla razón de que el PID puede tener un valor numérico máximo. Si un proceso tiene el PID más alto, ningún hijo que bifurca puede tener un PID mayor. La alternativa a darle al niño un PID más bajo sería fallar por fork()completo, lo que no sería muy productivo.

Los PID se asignan en orden, y después de usar el más alto, el sistema se ajusta para reutilizar los más bajos (gratuitos), por lo que también puede obtener PID más bajos para un niño en otros casos.

El PID máximo predeterminado en mi sistema ( /proc/sys/kernel/pid_max) es solo 32768, por lo que no es difícil alcanzar la condición en la que ocurre la envoltura.

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

Si su sistema asignara PID aleatoriamente ( como parece hacer OpenBSD ) en lugar de consecutivamente (como Linux), habría dos opciones. O bien, la elección aleatoria se realizó en todo el espacio de posibles PID, en cuyo caso sería obvio que el PID de un niño puede ser más bajo que el de los padres. O, el PID del niño se elegiría al azar de los valores mayores que el PID del padre, lo que en promedio lo ubicaría a la mitad del PID del padre y el máximo. Los procesos de bifurcación recursiva alcanzarían rápidamente el máximo y estaríamos en el mismo punto que se mencionó anteriormente: una nueva bifurcación necesitaría usar un PID más bajo para tener éxito.

— ilkkachu
fuente

FWIW, existen sistemas donde los PID se asignan aleatoriamente (por defecto en OpenBSD, por ejemplo), y estoy seguro de que también he visto un esquema de asignación de PID similar en Linux (o al menos he visto uno sugerido).

— Kusalananda

@Kusalananda, sí, creo que también ha habido una pregunta sobre eso en Unix.SE. No tengo tiempo para desenterrarlo, pero por lo que recuerdo, el parche para Linux que hizo una elección PID aleatoria era antiguo y se abandonó como innecesario. Sin embargo, no importa: siempre y cuando haya un PID máximo (relativamente bajo), una vez que se usa, las opciones son dar un PID más bajo o dejar caer un error en la bifurcación.

— ilkkachu

unix.stackexchange.com/questions/206096/… y unix.stackexchange.com/questions/401327/… para empezar

— Jeff Schaller

@ Massimo, el aspecto de seguridad se discute en esta pregunta en security.se: ¿Los PID aleatorios aportan más seguridad?

— ilkkachu

@RonJohn, bueno, no sé qué valores ponen otros Linux allí, pero es modificable, puedes configurarlo en aproximadamente 4 millones (4194304, o 2 ^ 22) en sistemas de 64 bits. (es un número, no una cantidad de bytes)

— ilkkachu

También existe el potencial de vulnerabilidades de seguridad utilizando notificaciones del núcleo y bifurcando para evitar ser detectado por un escaneo de la tabla de procesos; esto si se hace correctamente da como resultado que su proceso tenga un PID más bajo y las herramientas de proceso no vean el proceso en cuestión.

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

procps-ng, procps es vulnerable a un proceso que se oculta en condiciones de carrera. Dado que proc_pid_readdir () del núcleo devuelve entradas PID en orden numérico ascendente, un proceso que ocupa un PID alto puede usar eventos de inotificación para determinar cuándo se está escaneando la lista de procesos, y fork / exec para obtener un PID más bajo, evitando así la enumeración. Un atacante sin privilegios puede ocultar un proceso de las utilidades de procps-ng explotando una condición de carrera en las entradas de lectura / proc / PID. Esta vulnerabilidad afecta a procps y procps-ng hasta la versión 3.3.15, las versiones más recientes también podrían verse afectadas.

— thrig
fuente