[1635] in Kerberos_V5_Development
Re: kadm5_get_config_params vs. krb5_read_realm_params
daemon@ATHENA.MIT.EDU (Barry Jaspan)
Mon Aug 26 11:09:55 1996
Date: Mon, 26 Aug 1996 11:09:45 -0400
From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: epeisach@MIT.EDU
Cc: krbcore@MIT.EDU
In-Reply-To: <9608242319.AA25385@kangaroo.mit.edu> (epeisach@MIT.EDU)
You could have saved yourself some explanation by asking me first, but
your analysis of the situation is basically correct. To recap and
explain: krb5_realm_params existed in adm.h, part of the old admin
system, and essentially every program that wanted to read data out of
kdc.conf did so with its own copy of the profile-reading
structure-filling code. The KADM5 libraries, as well as clients and
servers, needed access to essentially the same data. Instead of
having a bunch of global variables, or changing kadm5_init to take a
zillion parameters, or having every program have to inline the code to
read kdc.conf explicitly, I decided to retain the krb5_realm_params in
a slightly modified form. So now individual programs can very easily
transfer options from the command line to kadm5_config_params and then
specify those params to the kadm5 libraries in a clean way.
All is not sunny and light, however. First, some existing code still
used krb5_realm_params (previously all the kdb5_* programs, but
kdb5_util doesn't and the others are history, so now only the KDC
remains) but also needed access to kadm5, so I had to put those
structures and functions into kadm5.h or else use both kadm5 and the
old admin system in the same program, thus mixing admin systems which
I decided would be BAD.
Second, the basic semantics of kdc.conf vs. krb5.conf and the way
krb5_realm_params used them is kinda screwy, and I did not fully
understand it when I created kadm5_config_params, so as a result
kadm5_config_params is kinda screwy and in need of some help. One
part of the confusion is that relations are not necessarily read from
sensical places in config files. For example, a number of relations
are read from the [realms] section that have no business being
there---for example, kadmind's acl file and dictionary file. There
are also some relations in krb5.conf and kdc.conf that I think ought
to be in the other file; or, perahps, that there shouldn't be two
separate files. Finally, the way that an "alternate profile" needs to
be accessed is silly and requires a large amount of duplicate code
(most of which is in alt_prof.c); I discussed this in a recent message
to krbdev.
Another piece of the confusion is that kadm5_config_params contains
information that is used both by the kadm5 libraries, kadm5 clients,
and kadm5 servers. This makes it necessary sometimes for clients and
servers to call kadm5_get_config_params from outside of libkadm5, and
that starts getting much uglier than I had hoped. I think a better
design would be to have kadm5_get_config_params deal only with data
relevant to libkadm5, and have application-specific data handled
directly by the application rather than putting the union of some app
data into a libkadm5 structure (even those the apps are all part of
kadm5).
Anyway, that's a brief dump. As you can see, a full solution is
probably going to tricky and subtle to get just right. I was
basically thinking that it works the way it is, we should not worry
about it for now, and we'll fix it later.
Barry
