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

たとえば、カーネル2.6以降。

システムで実行中のすべてのプロセスを監視します。

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

「反転」の特殊なケースを持つことは可能ですか？

いいえ、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

システムが連続的に（Linuxのように）代わりにPIDをランダムに（OpenBSDが行うように）割り当てる場合、2つのオプションがあります。可能性のあるPIDのスペース全体でランダムな選択が行われた場合、子のPIDが親のPIDよりも低くなる可能性があることは明らかです。または、子のPIDは、親のPIDよりも大きい値からランダムに選択されるため、平均して親のPIDと最大値の中間になります。その後、再帰的にフォークするプロセスはすぐに最大値に達し、上記と同じ時点になります。新しいフォークでは、成功するためにより低いPIDを使用する必要があります。

また、カーネル通知を使用し、プロセステーブルスキャンによる検出を回避するために自分自身をフォークするセキュリティ脆弱性の可能性があります。これを正しく行うと、プロセスの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のユーティリティからプロセスを隠すことができます。この脆弱性は、バージョン3.3.15までのprocpsとprocps-ngに影響しますが、新しいバージョンも影響を受ける可能性があります。