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
jfh@rpp386.cactus.org (John F. Haugh II) (09/29/90)
In article <18525:Sep2703:51:0090@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >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. I suggested this once to a co-worker as a "Concurrent User Set" just for laughs. I seem to recall that we both had a really good laugh and then went out and got drunk. There is little or nothing you get from this approach that you don't get from concurrent group sets. Of course, I still think you should be able to have a "set concurrent group IDs" program ;-) As for 65536 user limitation problems ... The cheap solution is to just make UIDs 32 bits. This is what was done in AIX 3.1 (over the protestations of our dear friends at AT&T, The Protectors Of The Holy Squid), and is now I understand being done with V.4. Ever the followers, never the leaders. In a really sick universe you would be known by your 32 bit user ID and your 32 bit host IP address. Perhaps this is an idea for Plan 9? -- John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 Domain: jfh@rpp386.cactus.org "SCCS, the source motel! Programs check in and never check out!" -- Ken Thompson
guy@auspex.auspex.com (Guy Harris) (09/30/90)
>The cheap solution is to just make UIDs 32 bits. This is what was >done in AIX 3.1 (over the protestations of our dear friends at AT&T, >The Protectors Of The Holy Squid), and is now I understand being >done with V.4. It is, at least for all systems conforming to any of the ABIs defined for S5R4; UIDs, GIDs, process ID's, inumbers, "dev_t"s, "int"s (yes, "int"s, no ABI-conforming system can have "int"s shorter than 32 bits), link counts, and file modes ("st_mode" in the "stat" structure) must be 32 bits or longer in any ABI-conforming system. >In a really sick universe you would be known by your 32 bit user ID >and your 32 bit host IP address. Said universe gets even sicker if, as, and when it converts to ISO....
goudreau@batgirl.rtp.dg.com (Bob Goudreau) (10/01/90)
In article <4110@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >>The cheap solution is to just make UIDs 32 bits. This is what was >>done in AIX 3.1 (over the protestations of our dear friends at AT&T, >>The Protectors Of The Holy Squid), and is now I understand being >>done with V.4. > >It is, at least for all systems conforming to any of the ABIs defined >for S5R4; UIDs, GIDs, process ID's, inumbers, "dev_t"s, "int"s (yes, >"int"s, no ABI-conforming system can have "int"s shorter than 32 bits), >link counts, and file modes ("st_mode" in the "stat" structure) must be >32 bits or longer in any ABI-conforming system. The M88000 Binary Compatability Standard (for systems based on Motorola's 88k) also specifies uid_t, gid_t, pid_t, mode_t, dev_t, etc. as 32-bit containers. Note that the BCS is based on V.3, not V.4 It's unfortunate that the NFS protocol only allocates 16 bits for device numbers. ---------------------------------------------------------------------- Bob Goudreau +1 919 248 6231 Data General Corporation 62 Alexander Drive goudreau@dg-rtp.dg.com