steve@arezzo.siemens.com (Steve Giovannetti) (11/01/90)
Has anyone come up with schemes for maintaining a single site-wide uid space? I am in the process of developing one for our site. The problem is a little tricky if you're talking about a site that is large enough not to distribute a single password file. The advantages of a single space are obvious when you do a lot of NFS cross mounting. I was thinking of a central uid database that would take a unique identification number from the person and hash it into a uid. Any thoughts? SGG
samlb@pioneer.arc.nasa.gov (Sam Bassett RCS) (11/04/90)
Oi veh, yes, do I have ideas . . . We have exactly that problem here at Ames -- dozens of computer systems and hundreds of users. The default has been for individual SAs to assign UIDs in rough numeric and chronological order when someone wants an account. When there are more than 2 machines on a network, this is obviously a recipe for chaos. Federal computer security policy has gotten people to thinking about this problem in the last 3 years or so, but there have been political problems -- there are two large groups who have standardized, but neither is going to accept "dictates" from the other. And the rest of the computer "owners" are not going to take any guff from either one of the large groups. The compromise that is being worked out (sloooooowly -- this place IS run by Civil Servants [sic], after all) is that the UNIX UID will be assigned by the people in the admin department who issue badges -- they have a proprietary hashing scheme that produces a unique ID number based on a number of things, they aren't part of any of the political power blocks, and they deal with EVERYBODY that comes into the center. The two critical things for the scheme to work are: 1) A MANDATE (no exceptions, troops!) from top management. 2) A neutral, trusted group to administer it. BTW, all of the SAs that I've talked to would LOVE to have a central UID registry -- saves lots of calling around, but the mid-level management wouldn't buy it. Several groups have already said that they will provide the machine, software, and other expertise to the pass-house people . . . Sam'l Bassett, Sterling Software @ NASA Ames Research Center, Moffett Field CA 94035 Work: (415) 604-4792; Home: (415) 969-2644 samlb@well.sf.ca.us samlb@ames.arc.nasa.gov <Disclaimer> := 'Sterling doesn't _have_ opinions -- much less NASA!'
scs@lokkur.dexter.mi.us (Steve Simmons) (11/05/90)
samlb@pioneer.arc.nasa.gov (Sam Bassett RCS) writes: > The compromise that is being worked out (sloooooowly -- this >place IS run by Civil Servants [sic], after all) is that the UNIX UID >will be assigned by the people in the admin department who issue badges >-- they have a proprietary hashing scheme that produces a unique ID >number . . . The two critical things for the scheme to work are: > 1) A MANDATE (no exceptions, troops!) from top management. > 2) A neutral, trusted group to administer it. > BTW, all of the SAs that I've talked to would LOVE to have a >central UID registry -- saves lots of calling around, but the mid-level >management wouldn't buy it. I doubt that present hashing algorithm just happens to return numbers less than 32K, which is the max uid on far too many UNIX boxes. A better solution which still meets your criteria is uniqname. It is a central repository that lets sites generate unique login ids and UID numbers. It's particularly useful for collections of systems where both the administration and the authority is distributed. Uniqname might avoid the objections to a central service because it is voluntary -- you can start it up and SAs use it without forcing anyone to do anything. Or is your mid-management really so paranoid they won't *allow* SAs to co-operate? Uniqname is available from ftp.ifs.umich.edu, in ~ftp/sysadm/uniqname. There's a paper describing it in the latest LISA Conference Proceedings, available for $18 ($15 for USENIX members) from the USENIX Association, 2560 Ninth Street, Berkeley, CA, 94710. -- " . . . within a nanometer (about a billionth of a yard) . . . " Reader's Digest, November 1990, pp. 31
fitz@wang.com (Tom Fitzgerald) (11/06/90)
steve@arezzo.siemens.com (Steve Giovannetti) writes: > Has anyone come up with schemes for maintaining a single site-wide uid > space? I am in the process of developing one for our site. We sleazed out of this one. Everyone's UID here is a function of their telephone extension. For most people, it's just the last 4 digits of the extension, but there are also some tricks to make sure that there are no collisions, that nobody's ID is in the range 0 to 200, and that there is a reserved space for UUCP logins and other inorganic accounts. If you can't do something equally sleazy, the central database sounds like the best bet. --- Tom Fitzgerald Wang Labs fitz@wang.com 1-508-967-5278 Lowell MA, USA ...!uunet!wang!fitz
samlb@pioneer.arc.nasa.gov (Sam Bassett RCS) (11/06/90)
In article <1990Nov5.003602.25290@lokkur.dexter.mi.us> scs@lokkur.dexter.mi.us (Steve Simmons) writes: >I doubt that present hashing algorithm just happens to return numbers >less than 32K, which is the max uid on far too many UNIX boxes. The present plans are to generate 1-up UIDs, not use the hash code generated, as I understand it -- that would be used internally by the Pass House people to differentiate John Smiths. >A >better solution which still meets your criteria is uniqname. It is >a central repository that lets sites generate unique login ids and >UID numbers. It's particularly useful for collections of systems where >both the administration and the authority is distributed. Hmm -- I will go have a look at that, but the standard pattern here is to have the login name be the person's last name (with initials to disambiguate Smiths, for instance. >Or is your mid-management really so paranoid >they won't *allow* SAs to co-operate? Not quite! :-) Sam'l Bassett, Sterling Software @ NASA Ames Research Center, Moffett Field CA 94035 Work: (415) 604-4792; Home: (415) 969-2644 samlb@well.sf.ca.us samlb@ames.arc.nasa.gov <Disclaimer> := 'Sterling doesn't _have_ opinions -- much less NASA!'
anthis@sleepy.UUCP (mike anthis) (11/21/90)
In article <avo7w9.8yc@wang.com>, fitz@wang.com (Tom Fitzgerald) writes: > steve@arezzo.siemens.com (Steve Giovannetti) writes: > > Has anyone come up with schemes for maintaining a single site-wide uid > > space? I am in the process of developing one for our site. > > We sleazed out of this one. Everyone's UID here is a function of their > telephone extension. For most people, it's just the last 4 digits of the > extension, but there are also some tricks to make sure that there are no > collisions, that nobody's ID is in the range 0 to 200, and that there is > a reserved space for UUCP logins and other inorganic accounts. My (SunOS) man page for sa(8) says: BUGS sa's execution time increases linearly with the magnitude of the largest positive user ID in /etc/passwd. I am wondering how big the UID's have to get for this to become a problem? Or is this not a problem for some other reasons? I guess this boils down to the question: how big is a _practical_ limit on UID space; is it the same as the _legal_ limit? If someone expresses interest, I'll summarize e-mailed replies. Yours, mike -- ---------------------------------------------------- Mike Anthis uunet!bcstec!sleepy!anthis 90% of good taste is found in 10% of the population. ----------------------------------------------------
gord@cs.UAlberta.CA (Gord Urquhart) (11/28/90)
>> steve@arezzo.siemens.com (Steve Giovannetti) writes: >> > Has anyone come up with schemes for maintaining a single site-wide uid >> > space? I am in the process of developing one for our site. >> The following was taken from a recent issue of Ralphnet-Digest: Recent work at the University of Michigan by the Institutional File System project (IFS) and Computer-Aided Engineering Network (CAEN) staff has resulted in the development and installation of software that will eventually ensure unique and user-specific login names across the entire UM campus. To date the software, UNIQNAME, encompasses five architectures--Sun, Ultrix, BSD, etc.--and has approximately 9,000 registered logins. The newsletter article that follows (deleted) briefly describes the research and development the project entailed. The article has been reprinted from the August 10, 1990 issue of Inside ITD (an internal UM newsletter). For more information contact the project coordinator, Bill Doster (billdo@um.ifs.umich.edu). The full text of the paper, which will be presented at LISA IV, is available upon request. ------------------------------------------------------------------------------- Gord Urquhart | gord@atropos.ucs.ualberta.ca Tech Support - University of Alberta | -------------------------------------------------------------------------------
mjr@hussar.dco.dec.com (Marcus J. Ranum) (11/28/90)
> steve@arezzo.siemens.com (Steve Giovannetti) writes: > Has anyone come up with schemes for maintaining a single site-wide uid >space? I am in the process of developing one for our site. There's a utility called 'zap' (now something like unify_uids) that was written at University of Maryland that is useful for doing the mapping over to your unified user-id space once you've sorted out the administration. It reads a map of uids, opens the superblock, and frobs the inodes - fast, sure, and deadly - superblock death from above. mjr. -- Good software will grow smaller and faster as time goes by and the code is improved and features that proved to be less useful are weeded out. [from the programming notebooks of a heretic, 1990]
chris@mimsy.umd.edu (Chris Torek) (11/28/90)
In article <1990Nov27.202949.29121@decuac.dec.com> mjr@hussar.dco.dec.com (Marcus J. Ranum) writes: >There's a utility called 'zap' (now something like unify_uids) >that was written at University of Maryland that is useful for doing the >mapping over to your unified user-id space once you've sorted out the >administration. It reads a map of uids, opens the superblock, and frobs >the inodes - fast, sure, and deadly - superblock death from above. Actually, `unify_uids' is the name of the whole package, which includes two programs called `mp' and `zap'. mp takes one `special' passwd file, N `regular' passwd files, and produces N new passwd files with unified uids and gids, along with N `map' files. zap applies one of these map files to the disk. The special file assigns particular IDs, such as `root = 0'; people not in the special file get IDs starting at 256 (or some other value of your choice). The package also includes a few programs for fixing up quota files and such. I wrote mp and zap, others wrote the others. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 405 2750) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris
lws@capybara.comm.wang.com (Lyle Seaman) (12/06/90)
anthis@sleepy.UUCP (mike anthis) writes: >In article <avo7w9.8yc@wang.com>, fitz@wang.com (Tom Fitzgerald) writes: >> We sleazed out of this one. Everyone's UID here is a function of their >> telephone extension. For most people, it's just the last 4 digits of the >> extension, but there are also some tricks to make sure that there are no > sa's execution time increases linearly with the magnitude of > the largest positive user ID in /etc/passwd. >I am wondering how big the UID's have to get for this to become a problem? Well, in my case, the highest UID is 72721 (whoops, better fix that, should be 2721) but should be 8745. I've got a Sun, and don't notice any problems with sa. Lyle X72322 lws@capybara.comm.wang.com