(Final?) krb5.Conf Lexer/Parser Proposal
jhutz at cmu.edu
Fri Jan 6 17:52:27 EST 2006
On Friday, January 06, 2006 05:07:28 PM -0500 Jeffrey Altman
<jaltman at mit.edu> wrote:
> The chaining functionality is exactly what we need for Kerberos
> profiles in order to allow for a public repository of realm
> configuration data to be stored and distributed while still
> allowing local administrators to install their own configuration
> file. Finalize would be important in this case to allow
> administrators to override entirely the data in the public krb5.conf
> file if it became out of date.
I don't currently use MIT Kerberos in my infrastructure. So the resolution
to this won't affect me directly, though it may affect what other
implementors decide to do.
However, in our environment we have a large number of configuration files
for which there is or can be a facility-wide file, a per-platform file, a
research-specific one, and one that is local to a given machine. In most
cases these are merged to produce the "real" file whenever one of the input
files is changed. For the centrally-distributed files, this happens
automatically; if a user changes the .local file, they have to know and
remember to run the merge tool manually.
When merges happen, entries in the more-specific files override those in
less-specific files. Sometimes the changes are additive, as for
/etc/services; sometimes it is possible to entirely replace an entry
provided by a less-specific file, or even remove it. For some input file
forms, we find this functionality extremely useful, or even critical.
Removing the capability from any of the places where it is currently
deployed would cause operational hardship for us.
It seems to me that this sort of deployment is exactly what the finalizer
is designed to enable. I don't know if there are people out there using
the capability now, but if there are, removing it is going to cause real
problems for them. I think "it's slightly easier to parse if we drop it"
is not much of a justification for doing so.
I would suggest that especially in a highly line-oriented parser, it should
not be too difficult to treat }* as a single token which can be used in all
the same places as } but with slightly different semantics.
> I think that maintaining a public repository of realm configuration
> data would be a worthwhile service.
I can't decide if this is a good idea or not. KDC locations are easy
enough to obtain via SRV record lookups, so the only reason to maintain a
database of them would be to support legacy realms and clients which don't
use them, as we do with the CellServDB. If people thought such a database
would be useful, I'd be happy to maintain one, as I already do for AFS.
Realm configuration other than server locations seems likely to have
security implications which would make it undesirable to trust any such
information coming from a "public" source. Indeed, the only per-realm
confiugration that appears in my krb5.conf other than server locations
relates to V4 principal name conversion and domain->realm mappings.
More information about the krbdev