>
> Thomas Richard Stevenson writes:
>
> > There must be some reason why the different DCE vendors didn't take
> > the NIS approach. Does anyone know what that might be (I know that DCE
> > does much more than NIS does, and I'm not suggesting for a second that
> > NIS does anything else (other then in this one small area) better then
> > DCE, so please lets not turn this into a religious war comparing NIS
> > and DCE)?
>
> The problem with the NIS approach is that the library (libc.a) has to
> know how to handle the passwd file. That means the protocol used to
> access the passwd file gets wired into every workstation, and every
> program. If you change the protocol, then all the libc's have to be
> changed, and all the programs that use libc have to be compatible with
> whatever the new routines are. Because the protocol gets used by
> untrusted programs, it's much harder to build proper security in. For
> instance, secret key encryption is right out, because the program isn't
> trusted. Public key technology has cumbersome domestic licensing.
> Either public or secret key technology when used in untrusted programs
> become a difficult export issue as well. NIS also has a serious scaling
> issue: every program goes out through libc directly to the network to
> get at the network database; so network load goes up more or less
> as the square of the size of the user population (it's the product
> of the size of the passwd file & the # of machines).
>
> The obvious solution is to make some sort of local machine copy of the
> passwd file. This reduces the the network load, because the contents
> of the file now merely need be propagated once when changed on a
> per-machine basis, not heavily redundantly piecemeal when needed on a
> per-process basis. A monolithic trusted program now copies the file, so
> secret key encryption can be used, & export issues become simplier to
> resolve. Machine dependencies can then also be sorted out on a
> per-machine basis by merging in some sort of local file and resolving
> any conflicts in favor of the the local file.
>
> Just to add
> insult to injury, the limit isn't even 65535, that whole range around
> 60000 and above is a problem too, and there's even sort of another one
> at about 32767, and of course, anything under 100 (or more usually,
> under 1000) is just plain bad news.
Heh Heh. Don't forget about Ultrix, which does very dangerous things
if you have UID's bigger than 32000. I'm sure jjc can recall the fun
the University of Pittsburgh had when they ran into that problem...
-- Jeffrey T. Hutzelman (N3NHS) <[EMAIL PROTECTED]>
Systems Programmer, CMU SCS Research Facility
Please send requests and problem reports to [EMAIL PROTECTED]
