PID ของกระบวนการลูกนั้นใหญ่กว่า PID ของพาเรนต์บน Linux เสมอหรือไม่?

สมมุติว่าจากเคอร์เนล 2.6 เป็นต้นไป

ฉันดูกระบวนการทำงานทั้งหมดในระบบ

PID ของเด็ก ๆ นั้นดีกว่า PID ของผู้ปกครองหรือไม่?

เป็นไปได้หรือไม่ที่จะมีกรณีพิเศษของ "การผกผัน"?

ไม่เพราะเหตุผลง่ายๆที่มีค่าตัวเลขสูงสุด PID สามารถมีได้ หากกระบวนการมี PID สูงสุดเด็กจะไม่สามารถมี PID ได้มากกว่า ทางเลือกในการให้ PID ที่ต่ำกว่าแก่เด็กก็คือการล้มเหลวfork()ทั้งหมดซึ่งจะไม่เกิดผลมากนัก

PID จะถูกจัดสรรตามลำดับและหลังจากที่ใช้สูงสุดระบบจะล้อมรอบเพื่อนำส่วนที่ต่ำกว่า (ฟรี) กลับมาใช้ใหม่ดังนั้นคุณสามารถรับ PID ที่ต่ำกว่าสำหรับเด็กในกรณีอื่นได้เช่นกัน

PID สูงสุดเริ่มต้นในระบบของฉัน ( /proc/sys/kernel/pid_max) เป็นเพียง 32768 ดังนั้นจึงไม่ยากที่จะเข้าถึงสภาพที่เกิดการพัน

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

หากระบบของคุณต้องจัดสรร PID แบบสุ่ม ( เช่น OpenBSD ดูเหมือนจะทำ ) แทนที่จะต่อเนื่องกัน (เช่น Linux) จะมีสองตัวเลือก ตัวเลือกแบบสุ่มถูกสร้างขึ้นทั่วพื้นที่ทั้งหมดของ 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 ที่ต่ำกว่าดังนั้นหลีกเลี่ยงการแจงนับ ผู้โจมตีที่ไม่ได้รับสิทธิพิเศษสามารถซ่อนกระบวนการจากยูทิลิตี procps-ng โดยใช้ประโยชน์จากสภาพการแข่งขันในการอ่าน / proc / PID รายการ ช่องโหว่นี้ส่งผลกระทบต่อ procps และ procps-ng จนถึงรุ่น 3.3.15 ซึ่งอาจมีผลกระทบต่อเวอร์ชันที่ใหม่กว่า