gwyn@smoke.BRL.MIL (Doug Gwyn) (06/28/89)
In article <1839@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >I suspect future SunOS releases, and the NFS source releases derived >from them, will follow 4.xBSD and S5 and have unsigned UIDs ... Great, the negative IDs were a hassle. >Separate issue(s): 1) RFS-style mapping has, I think, been implemented >by Cray, and 2) RFS also has, I think, the same notion of a "nobody" UID. Given a choice between the Yellow Pages and RFS approaches to ID mapping, I much prefer the RFS style. Rather than adopt Yellow Pages here when we first installed NFS, we tossed YP and instead went to a "campus-wide" global UID scheme. I'm not recommending that, but it shows what low regard some sites had for YP. I don't claim to be an expert, I just watched this stuff happen.
ed@mtxinu.COM (Ed Gould) (06/29/89)
>Given a choice between the Yellow Pages and RFS approaches to ID mapping, >I much prefer the RFS style. Rather than adopt Yellow Pages here when we >first installed NFS, we tossed YP and instead went to a "campus-wide" >global UID scheme. I'm not recommending that, but it shows what low >regard some sites had for YP. Very few people, including some developers at Sun, hold YP in high regard. But YP and UID mapping address separate issues. Adopting an administrative solution to a global UID space (e.g., assigning ranges of UIDs to different groups) is often a very good idea. It's probably better than a single-administration scheme like YP. UID mapping, on the other hand, addresses the situation where it is not feasable or reasonable to demand a global UID space. Maps are typically per server-client pair, so any general mapping can be implemented. Note that mapping is potentially either expensive or introduces problems of its own. Maybe we should go to something like the Ethernet scheme: Use 80-bit UIDs built as follows. The low-order 16 bits are the current UID, treated as an unsigned quantity, and assigned by the "user" (in this case the administrator) of each system. The upper 64 bits are divided into two 32-bit quantities. The high-order 32 bits are assigned from a global registry of UID-using manufacturers. Each manufacturer assigns a unique number to each system in the low-order 32 bits. Is this enough bits (2^32 manufacturers, 2^32 systems/manufacturer, 64K users/system)? Where do we store all of this junk? -- Ed Gould mt Xinu, 2560 Ninth St., Berkeley, CA 94710 USA ed@mtxinu.COM +1 415 644 0146 "I'll fight them as a woman, not a lady. I'll fight them as an engineer."
gwyn@smoke.BRL.MIL (Doug Gwyn) (07/01/89)
In article <903@mtxinu.UUCP> ed@mtxinu.COM (Ed Gould) writes: >Maybe we should go to something like the Ethernet scheme: Use 80-bit >UIDs built as follows. ... This is getting very close to the "capability" concept.
dls@mace.cc.purdue.edu (David L Stevens) (07/01/89)
IP address is better than Ethernet address, though. "Manufacturer" ties "universal IDs" to hardware that's widely distributed, where an <IPaddr,uid> pair helps you find someone in the global community of ids. Routing information is encoded in the uid *and* the IP addresses are already assigned. In fact, translating "user@host" into a 6-byte <IPaddr,uid> is trivial. This probably shouldn't stay in bugs.4bsd; guilty as charged. -- +-DLS (dls@mace.cc.purdue.edu)
ed@mtxinu.COM (Ed Gould) (07/01/89)
>>Maybe we should go to something like the Ethernet scheme: Use 80-bit >>UIDs built as follows. ... > >This is getting very close to the "capability" concept. No, capabilities are really much more than UIDs: They don't just identify an object, they contain access rights as well. And, usually (although there's no real reason for this limit), capabilities identify only system-managed objects like files and processes, not users. I was just suggesting a truely global UID scheme. -- Ed Gould mt Xinu, 2560 Ninth St., Berkeley, CA 94710 USA ed@mtxinu.COM +1 415 644 0146 "I'll fight them as a woman, not a lady. I'll fight them as an engineer."