On Sat, Feb 17, 2024 at 10:31:29PM +0000, Matthew Wilcox wrote: > On Sat, Feb 17, 2024 at 03:56:40PM -0500, Kent Overstreet wrote: > > AKA - integer identifiers considered harmful > > Sure, but how far are you willing to take this? You've recently been > complaining about inode numbers: > https://lore.kernel.org/linux-fsdevel/20231211233231.oiazgkqs7yahruuw@xxxxxxxxxxxxxx/ > > > The solution (originally from plan9, of course) is - UIDs shouldn't be > > numbers, they should be strings; and additionally, the strings should be > > paths. > > > > Then, if 'alice' is a user, 'alice.foo' and 'alice.bar' would be > > subusers, created by alice without any privileged operations or mucking > > with outside system state, and 'alice' would be superuser w.r.t. > > 'alice.foo' and 'alice.bar'. > > Waitwaitwait. You start out saying "they are paths" and then you use > '.' as the path separator. I mean, I come from a tradition that *does* > use '.' as the path separator (RISC OS, from Acorn DFS, which I believe > was influenced by the Phoenix command interpreter), but Unix tends to > use / as the separator. To me, / indicates that it's a filesystem object, which these are not. Languages tend to use : as the path separator for object namespacing - heirarchical paths, but not filesystem paths. > One of the critical things about plan9 that means you have to think > hard before transposing its ideas to Linux is that it doesn't have suid > programs. So if I create willy/root, it's essential that a program > which is suid only becomes suid with respect to other programs inside > willy's domain. And it doesn't just apply to filesystem things, but > "can I send signals" and dozens of other things. So there's a lot > to be fleshed out here. My proposal is that a user is superuser only over direct sub-users; so in your example, willy.root would only be superuser over willy.root.*; it's just your normal willy user that's superuser over all your sub-users. That means that our 'root' user doesn't fit with this scheme - the superuser over the whole system would be the "" user. Or perhaps we just map our existing users to be sub-users of root? root root.willy root.kent? User namespacing in this scheme just becomes "prepend this username when leaving the namespace", so this might actually work; bit odd in that in this scheme there's nothing implicitly special about the 'root' username, so that becomes a (mild) wart... easily addressed with capabilities, though.
