brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (09/27/90)
Say uids are strings of 16-bit words, terminated by 0. A uid controls any uid it's a prefix of. A program setuid from uid x to uid y runs as the concatenated euid y+x, with real uid x; here an otherwise unused word, +, might be placed between y and x. A process can setuid to any uid that it controls. Clearly the first word of a string uid works exactly like the current uid permissions: uid 0 (the empty string) controls all uids, and other uids control just themselves. So it's a backwards-compatible change. String uids make security policies much easier to implement. Subaccounts are absolutely trivial to set up. A program setuid to uid y+x can access something in group y+*, without any risk of being able to kill other setuid-y processes. (This means that a bug isn't automatically a security hole, even in setuid programs.) String uids fit naturally with a merged uid-gid space, where processes and objects have a primary uid and zero or more secondary uids. Of course, string uids also break the 65536-user barrier. Note that the system might set some arbitrary limit on the length of uids. It'd have to somehow prevent setuid euids from being chopped. Perhaps euids could be given a larger limit, and uid-euid switching could be dropped in favor of saved uids. Comments? Followups to comp.unix.futures. Uh, make that comp.unix.kernel. Nope, try comp.unix.wizards. Oops, that's comp.unix.internals. [sigh] ---Dan