String uids for power and security

[Dan Bernstein]

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