Mapping of RIDs to uid_t and gid_t

[David Collier-Brown]

I wrote:
> >         Therefor ((uid+1000) & 28bits) may cause loss of
> >         significant digits. **May**!  It's probabilistic...
> >
> >         Are the group and machine ID's randomly distributed, or are
> >         they individually counted up from 0?  I'm having a half-baked
> >         thought (;-))

>Jeremy Allison wrote:
>  *Everything* - machine accounts, user accounts, groups
> etc. are mapped into the 32 bit RID space.

	Hmmmn, that's not as bad as I feared...

	Check me on this, folks:  unix uids start at zero,
	and increase linearly for a few numbers, then hop
	up to a higher value (e.g., 100 on old unixes, 1000 on
	a few new ones), continue for a while, usually with
	holes (:-)), then hop again to a ``very high'' value
	like -1.

	My Solaris machine says:
root:x:0:1:Super-User:/:/sbin/sh
daemon:x:1:1::/:
bin:x:2:2::/usr/bin:
sys:x:3:3::/:
adm:x:4:4:Admin:/var/adm:
lp:x:7:8:Line Printer Admin:/usr/spool/lp:
smtp:x:0:0:Mail Daemon User:/:
uucp:x:5:5:uucp Admin:/usr/lib/uucp:
nuucp:x:9:9:uucp Admin:/var/spool/uucppublic:/usr/lib/uucp/uucico
listen:x:37:4:Network Admin:/usr/net/nls:
nobody:x:60001:60001:Nobody:/:
noaccess:x:60002:60002:No Access User:/:
nobody4:x:65534:65534:SunOS 4.x Nobody:/:

	This means that there is a little hole between the
top of the system account uids and 100, and a big one above
-32k, followed by a few ``minus numbers''. The big hole makes 
(28 bits of uid + 1000) safe in many cases, as Jeremy noticed.

	If true, we have two number lines like this where the x's
indicate unix uid's are (probabilistically) present


Uid	|xxxx  xxxxxxxxxxx  xx xx   |                     x   xx|
	+---------------------------+---------------------------+ 
        |     |     |                n-1                         n
	0    100  1000              2                           2

NT RID
        |                                                       |
	+---------------------------+---------------------------+ 
        |                            n-1                         n
        0                           2                           2

	If we fold the negative numbers down adjacent to the uids,
this only requires us to fold a smallish range plus four
bits of attributes into a quite large range.

	I'd put the -1 ,60001 crew individually down at 0, followed 
by uid+1000, all in the 28 bits of space we have... for 32-bit Unix.
	Any SGI or DEC folks out there (:-))


--dave (running beta 32-bits on a 64-bit processor while
	my neighbour runs alpha 64-bits on a 64-bit processor) c-b
-- 
David Collier-Brown,  | Always do right. This will gratify some people
185 Ellerslie Ave.,   | and astonish the rest.        -- Mark Twain
Willowdale, Ontario   | davecb at hobbes.ss.org, canada.sun.com
M2N 1Y3. 416-223-8968 | http://java.science.yorku.ca/~davecb