(Final?) krb5.Conf Lexer/Parser Proposal

[Jeffrey Hutzelman]

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.

-- Jeff


> 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.

-- Jeff