Completing the pidfd API

Posted Jun 14, 2023 2:44 UTC (Wed) by jredfox_ (guest, #165585)
Parent article: Completing the pidfd API

This is a quick fix for an invalid solution. the proper solution is the PID solution. you should have in the arguments PID-CREATIONTIME where creation time is MS preferably. I don't like JIFFIES or UNIX seconds it's not precise enough.

Or an even better solution create a call called reservePID(unsigned long PID). this will reserve the PID until the process that called it is closed. For security reasons it should limit the number of reserves it can use to about 200 PID's for IPC(unrelated non child process's) per process and unlimited amount for child process's.

Completing the pidfd API

Posted Jun 14, 2023 5:07 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

> you should have in the arguments PID-CREATIONTIME where creation time is MS preferably. I don't like JIFFIES or UNIX seconds it's not precise enough.

Why not UUIDs then?

And pidreserve doesn't prevent all race attacks.

Completing the pidfd API

Posted Jun 14, 2023 23:23 UTC (Wed) by jredfox_ (guest, #165585) [Link] (1 responses)

UUIDS MS creation time is way over 700! Also UUID collisions can and have occurred. currentMS states the current ms the creation time was fetched and the creation time of the process never changes. UUID's are problematic

Completing the pidfd API

Posted Jun 15, 2023 1:42 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

Version 1 and 2 UUIDs include system time, so they can't collide unless the kernel is compromised.

But more practically, your system with time-based IDs is just ugly, just like UUIDs.

And pidreserve() won't help against targeted wraparound attacks.