Process ids again

FYI, Landlock IDs follow this approach. One important difference is that we only need a bijection (i.e. Landlock IDs are not used to get a reference but only to identify an existing object). From the commit description, Landlock IDs have these properties:
- They are unique during the lifetime of the running system thanks to
the 64-bit values: at worse, 2^60 - 2*2^32 useful IDs.
- They are always greater than 2^32 and must then be stored in 64-bit
integer types.
- The initial ID (at boot time) is randomly picked between 2^32 and
2^33, which limits collisions in logs across different boots.
- IDs are sequential, which enables users to order them.
- IDs may not be consecutive but increase with a random 2^4 step, which
limits side channels.

For more details, see https://git.kernel.org/torvalds/c/d9d2a68ed44bbae598a81cb...

Would that really help with anything though, given the sequence is still entirely predictable?

I absolutely do stuff other than act as a copypaste bot. Including looking at logs, and correlating things across multiple sources. I almost never need to actually kill processes by ID.

Long IDs make that harder.

> PID namespaces

That looks like a big big can of worms.

How do non-updated apps and updated ones mix? Say an updated shell trying to start an old app or vice-versa?
Or do you expect the user to use different launcher/shell and choose which to interact with depending on what type of apps they use? And have different binaries with different pid size for apps used in both (shell, launcher, UI, ssh, ...)?
How do apps communicates pids with each other if they are not in the same namespace? Say someone uses an updated "top" command and thus gets 64-bit pids, then try to use the shell's builtin "kill" command which is still expecting 32-bit pid?

What/who decides what namespace to use? The kernel? The shell/launcher? The user? How does it/he/she know what namespace to use?

Namespaces work well if a whole ecosystem can be independent from everything else wrt to that namespace. They also work because only values changes, not the types, the binaries are the same (i.e. a shell in one namespace can work as well in another, they will just print different values for pids, or see different files, ...)

> A shell script needs no update for 64-bit process ids

Most won't, but a script can still make assumption on the pid size, e.g. it only contains 10 digits.

> A C program using pid_t may just need a recompile

Keyword "may".
And even for the simple cases, this depends a lot on how 64-bits pids would be implemented, e.g. would this be a compilation flag? Or a "#define USE_PID64"? Or would this be changing all the "pid_t"/"getpid()"/... to "pid64_t"/"getpid64()"/...?

And in the non-simple cases, the issues are the same for 64-bits pids and pidfds (apps using pid in a "smart" way will be majorly broken, pid64/pidfd cannot be passed as-is when communicating a 32-bit pid apps, ...).

> I imagine a compiler warning can mostly catch this

Only in simple cases, maybe. And AFAIK, currently, compilers will not complain when storing a in64_t in an int32_t without the "-Wconversion" flag (which is not enabled even when using "-Wall -Wextra -pedantic"). And even "-Wconversion" will not complain if there is a cast involved. https://godbolt.org/z/z3jGbYb86

> there will be some code putting a process id into an int

Or putting it in the low bits of an int64_t then use the high bits for something else.
Or assume that a struct containing a pid has a specific size. Or that fields in that struct after the pid are at specific offsets.
Or ... (don't underestimate what people do when they assume something will be true forever)...

Basically, one can look at what happened during then transition from 32-bit to 64-bit platforms, the switch to large file (>4GB), and the Y38 problems, to see all the possible issues than can arise.

> Rewriting a C program to use pidfds is a much bigger task

I'm not so sure. Since a pidfd is actually a pid_t type, and depending on what pid/pidfd are used for, updating could boil down to calling "pidfd_xyz()" instead of "xyz()", or passing a "XYZ_PIDFD" flag.

For the rest, that can be a big task to fix in either case. For instance, if the problem is someone combining the pid with something else in an int64_t, then a pidfd will still work fine, while the pid64 will need a redesign.
Or people might make the same assumption that you did, that pid64 is just a recompilation, then spend a lot of time tracking down bugs. While with pidfs, they would spend time looking at each call sites first, fixing the problems before they arise and need tracking.
Which one will take more time will depend on the applications. Sometimes it's faster to think things through first, some others it faster to just try&fix. This very much apply here IMHO.

> A C program using pid_t may just need a recompile

You are assuming a properly carefully wrritten program..there is still code out there that assumes pids are 16 bit and store them in a ushort..There is incorrect casting, there is code not using pid_t at all.. I mean there is a lot of buggy software out there...

> Start time of the process can't be changed by the process itself AFAIK. Just that along with the pid could do the trick, IMHO.

It very much doesn't, so-much-so that relying on that combination for uniqueness caused several CVEs in the past. The start time is not granular enough, and attackers are able to cause a PID + start time clash at their leisure. This is why PIDFDs exist, and we use them when we need to uniquely identify processes for any security-relevant reason (and also more and more non-security-relevant too)