2 ms·
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 prett
by lomnakkus 8y ago
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.
- fowl2 8y agoExcept of course if you want multiple instances of the same daemon
- lomnakkus 8y agoUm, 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.
- JdeBP 8y agoOne 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.