자식 프로세스의 PID가 Linux에서 부모 프로세스의 PID보다 항상 더 큽니까?


22

커널 2.6부터 말해 보자.

시스템에서 실행중인 모든 프로세스를 봅니다.

어린이의 PID는 항상 부모의 PID보다 큽니까?

특별한 "반전"사례가있을 수 있습니까?

답변:


47

아니요, PID가 가질 수있는 최대 숫자 값이 있다는 매우 간단한 이유입니다. 프로세스의 PID가 가장 높으면 포크가 더 큰 PID를 가질 수있는 자식이 없습니다. 아이에게 PID를 낮추는 대안은 fork()완전히 실패하는 것 입니다. 이는 매우 생산적이지 않습니다.

PID는 순서대로 할당되며, 가장 높은 것을 사용한 후에는 시스템이 (무료) 하위를 재사용하기 위해 랩핑하므로 다른 경우에도 하위의 PID를 얻을 수 있습니다.

내 시스템 ( /proc/sys/kernel/pid_max) 의 기본 최대 PID 는 32768이므로 랩 어라운드가 발생하는 조건에 도달하는 것은 어렵지 않습니다.

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

시스템이 Linux와 같이 연속적으로 PID를 무작위로 할당하는 경우 ( OpenBSD가하는 것처럼 ), 두 가지 옵션이 있습니다. 가능한 PID의 전체 공간에 대해 무작위 선택이 이루어졌으며,이 경우 자녀의 PID가 부모의 PID보다 낮을 수 있음이 분명합니다. 또는 자식의 PID는 부모의 PID보다 큰 값에서 임의로 선택되어 부모의 PID와 최대 값의 중간에 있습니다. 재귀 적으로 포크하는 프로세스는 빠르게 최대 값에 도달 할 것이고 우리는 위에서 언급 한 것과 같은 시점에있을 것입니다. 새로운 포크는 더 낮은 PID를 사용해야 성공할 수 있습니다.


3
FWIW에는 PID가 무작위로 할당되는 시스템 (예 : OpenBSD에서 기본적으로)이 있으며 Linux에서도 비슷한 PID 할당 체계를 보았거나 적어도 제안 된 시스템이 있습니다.
Kusalananda

@ Kusalananda, 그렇다. 나는 unix.SE에서도 그것에 대한 질문이 있다고 생각한다. 나는 그것을 파헤칠 시간이 없지만, 내가 기억하는 한, 임의의 PID 선택을 한 Linux 패치는 오래되고 불필요하게 버려졌습니다. 그것은 중요하지 않습니다 : (상대적으로 낮은) 최대 PID가있는 한, 일단 사용되면 선택은 더 낮은 PID를 주거나 포크에 오류를 줄입니다.
ilkkachu


2
@Massimo, 보안 측면은 security.se에 대한이 질문에서 논의됩니다 : 무작위 PID는 더 많은 보안을 가져
ilkkachu

1
@RonJohn, 글쎄, 나는 다른 리눅스가 가치를 두는 것이 아니라 수정할 수 있지만 64 비트 시스템에서 약 4 백만 (4194304 또는 2 ^ 22)으로 설정할 수 있습니다. (바이트가 아닌 숫자 임)
ilkkachu

8

또한 커널 알림을 사용하고 프로세스 테이블 스캔에 의한 탐지를 피하도록 보안 취약점을 일으킬 가능성이 있습니다. 이 작업을 올바르게 수행하면 프로세스의 PID가 낮아지고 프로세스 도구가 해당 프로세스를 보지 못하게됩니다.

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

procps-ng, procps는 경쟁 조건을 통해 숨기는 프로세스에 취약합니다. 커널의 proc_pid_readdir ()은 PID 항목을 오름차순으로 반환하므로 높은 PID를 점유하는 프로세스는 inotify 이벤트를 사용하여 프로세스 목록이 스캔되는시기를 판별하고 fork / exec를 사용하여 더 낮은 PID를 얻을 수 있으므로 열거를 피할 수 있습니다. 권한이없는 공격자는 / proc / PID 항목을 읽을 때 경쟁 조건을 이용하여 procps-ng의 유틸리티에서 프로세스를 숨길 수 있습니다. 이 취약점은 procps 및 procps-ng 버전 3.3.15에 영향을 미치며 최신 버전에도 영향을 줄 수 있습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.