[EMAIL PROTECTED]
Subject: Re: defining system accounts and groups in DCE or AFS
In-Reply-To: Your message of "Fri, 14 Jun 96 10:34:52 BST."
<[EMAIL PROTECTED]>
Date: Fri, 14 Jun 96 16:35:39 -0400
From: Marcus Watts <[EMAIL PROTECTED]>
>
> The keyboard of Marcus Watts emitted at some point in time:
> >
> >
> > Thomas Richard Stevenson writes:
> >
> > > There must be some reason why the different DCE vendors didn't take
> > > the NIS approach.
> ....
>
> > 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.
>
> That may be the way it is, but not the way it "has to be".
That *is* the way it is in NIS.
>
> > 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.
>
> ... Or use shared objects ...
libc on most modern machines *is* a shared library. So?
Shared libraries are no panacea for compatibility. You can
get very strange problems if routines like getpwent/getpwnam
start behaving "differently". For instance, I once ran
into some *very* strange problems in a program that did
a "getpwnam", then a "vfork" followed by a "initgroups", when I
linked it with a different implementation of getpwent/getpwnam.
Turns out the new implementation of getpwnam left some
file descriptors open. initgroups managed to close
those descriptors, but because the program had vfork'd,
it didn't manage to close the descriptors in the parent.
This resulted in a nice file descriptor leak in the parent,
which sure enough threw up after it had been running for a while.
Moral of the story: software quality control is not as simple
as it looks.
>
> > The obvious solution is to make some sort of local machine copy of the
> > passwd file.
>
> Rubbish.
>
> It is amazing how essentially the same problem gets solved differently
> in different approaches, with both parties claiming that they found the
> only way to do it. I see no fundamental difference between validating
> users and resolving machine names to IP numbers. It is just that the
> network people had the clear view that the solution had to work
> globally if it was to be any use, and that a single "authoritative"
> database was impossible.
>
> I also do not see why the DNS approach - and most of the software -
> could not be used for resolving usernames. Then any machine could
> assign system account uid's to its heart's content, with few clashes.
I never claimed the "obvious" was the only way.
DNS is not NIS. DNS, in fact, has some important and
distinct advantages over NIS. As it happens, NIS can
also be used to resolve machine names, and for a long
time, Sun was pushing NIS big-time for just this use.
Even so, NIS never really caught on for this use,
perhaps because it doesn't scale well.
There are, indeed, some very nice things about DNS.
Good things about DNS:
scales well
distributed hierarchical authority delegation
vendor independent protocol
cheap high quality public implementation
widely used
In my last message, I stated some "hard" problems
for a username database, and they include some
things that DNS doesn't do particularly well:
for instance,
wildcard lookups (a la finger, sendmail)
-> actually translates into sequential
access to the whole db, 'cause that's
the only libc API and hence the only
choice in sendmail & finger.
no encryption based security. There are,
indeed, fairly persistant stories about
people pumping all sorts of junk into
named to confuse them, for various nefarious
reasons.
While DNS scales well in the sense of
clusters of hundreds of machines, I
doubt it would scal as well when faced
with 10's or hundreds of thousands of
users. I've seen some pretty bloated
named's, & some pretty frustrating
failure modes.
There are two more "obvious" ways to deal with a
username database, hesiod, and X.500. I don't
know as much about hesiod as I should. X.500
is used here on the UM campus. Indeed, it
does some very nifty things, but it is definitely
not a no brainer, and not a drop-in replacement for
/etc/passwd. There are several commercial systems that
do use X.500-like databases for a username database.
For instance, Novell netware 4.x's NDS springs to mind,
and I kind of recall DCE had something too.
I think part of the problem here is a matter
of terminology. NIS means a lot more than just
"the + user at the end of the password file". DNS
means a lot more than "running named on your local
workstation". There are a lot of parts to a username
database, including the "getpwent/getpwnam" API's
in libc, the propagation strategy used to get it to the
workstation, central server replication strategies,
administrative tools, and lots more. Each step has important
tradeoffs in terms of speed, compatibility, trustworthiness,
simplicity of administration, and scalability. In
order to have a meaningful discussion about the tradeoffs,
it's important to be precise about which part of
what thing you mean. Otherwise, in the words of the
immortal MPFC, "Do you realize Mr. Gabriello, some of
those guys out there paid over $2,000 for a ringside seat."
[Ep.43, II.302]
-Marcus Watts
UM ITD PD&D Umich Systems Group
