[lomnakkus]

Personally, I think even having to choose a UID at install time or dynamically is a pretty sad indictment of just how broken the user system on Linux (and pretty much every UNIX-like) is. It leads to a huge amount of incidental complexity where there's a much simpler way: User IDs should just be randomly chosen UUIDs -- either generated by upstreams or by the distros. Any metadata attached to the user UID could just be preinstalled for all possible daemons[0] -- and it should be separate from the mutable /etc/passwd stuff.

Obviously there's so much inertia in the existing system that it could realistically never happen at this point, but one can dream, right?

[0] Kind of like e.g. /etc/services but with UUIDs.

[JdeBP]

One can, and many people have, over the years.

Some of the more interesting ideas that people have had, in my view, have been:

* ID systems that introduce hierarchies, allowing (say) a user to create multiple sub-users (one for running the WWW browser, one for running the office suite, one for running the chat program, ...);

* proper nonce ID creation with segregation guarantees (c.f. nonce SIDs in the Windows NT world); and

* IDs that are reference counted, accessible via descriptors, passable from process to process via descriptor-passing mechanisms, and explicitly supplied in system calls for opening/creating things.

[fowl2]

Except of course if you want multiple instances of the same daemon

[lomnakkus]

Um, mix in a second randomly-chosen UUID?

My point wasn't so much that I had the perfect solution and that I'd thought of everything. It's that there are much better systems and that we should actually strive to get there.