Path: utzoo!attcan!uunet!aplcen!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!execu!sequoia!rpp386!jfh
From: jfh@rpp386.cactus.org (John F. Haugh II)
Newsgroups: comp.unix.internals
Subject: Re: String uids for power and security
Message-ID: <18553@rpp386.cactus.org>
Date: 29 Sep 90 00:40:20 GMT
References: <8611@fy.sei.cmu.edu> <18525:Sep2703:51:0090@kramden.acf.nyu.edu>
Reply-To: jfh@rpp386.cactus.org (John F. Haugh II)
Organization: Lone Star Cafe and BBS Service
Lines: 29
X-Clever-Slogan: Recycle or Die.

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