☰

Linuxでは、子プロセスのPIDは常に親プロセスのPIDよりも大きいですか？

tag-icon • tag-icon linux-kernel process
Linuxでは、子プロセスのPIDは常に親プロセスのPIDよりも大きいですか？

カーネル2.6から始まるとします。

私はシステムで実行されているすべてのプロセスを観察します。

子のPIDは常に親のPIDよりも大きいですか？

「反転」が可能な特別な状況はありますか？

答え1

いいえ、PIDが最大数値を持つことができるという単純な理由による。プロセスのPIDが最も高い場合、そのプロセスが分岐する子プロセスはより大きなPIDを持つことができません。サブアイテムに低いPIDを提供するのではなく、完全に失敗する方法がありますがfork()、これはあまり生産的ではありません。

PIDは順番に割り当てられ、最も高いPIDが使用された後、システムは低いPIDを再利用（アイドル）し、他の状況でも子プロセスのためのより低いPIDを得ることができます。

私のシステムのデフォルトの最大PID（）/proc/sys/kernel/pid_maxは32768なので、ラップアラウンドが発生する条件を達成することは難しくありません。

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

システムがPIDをランダムに割り当てる場合（OpenBSDのように）連続（Linuxなど）の代わりに2つのオプションがあります。可能なすべてのPID空間からランダムに選択します。この場合、子プロセスの PID が親プロセスの PID より低い場合があります。あるいは、子プロセスのＰＩＤは、上位ＰＩＤより大きい値からランダムに選択され、平均して上位ＰＩＤと最大値との間に配置される。再帰的なフォークプロセスはすぐに最大値に達し、上記のものと同じポイントに達します。新しいフォークが成功するには、より低いPIDを使用する必要があります。

答え2

また、カーネル通知を使用し、プロセステーブルスキャンによる検出を避けるために自分自身を分岐する可能性のあるセキュリティホールがあります。正しく実行すると、プロセスの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 まで影響を及ぼし、最新バージョンも影響を受ける可能性があります。

関連情報