(Final?) krb5.Conf Lexer/Parser Proposal

[Alexandra Ellwood]

On Jan 6, 2006, at 5:07 PM, Jeffrey Altman wrote:

> One of the problems that the OpenAFS community has faced with the
> CellServDB file distribution is that there has been no method for
> a system administrator to install a public configuration file and
> update it to include local modifications without altering the
> contents of the public file.  This has caused significant problems
> with keeping CellServDB files up to date in an automated manner
> as there is no algorithm that can be used to synchronize a locally
> installed CellServDB file and one distributed in an OpenAFS update
> package.   (* There is a tool that Chaskiel Grundman wrote that
> does automate a merge and handles most cases.  However, it fails
> if the modifications were to remove server entries for example to
> rely on AFSDB instead of the CellServDB for a cell. *)
>
> 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.

Are you talking about a public config file that is distributed over  
the network or one that comes with the Kerberos distribution and is  
stored on the machine's local disk?

Distributing it over the network seems like a bad idea since it runs  
afoul of all the same problem as exporting domain_realm information  
over insecure DNS SRV records.  Even distributing realm information  
violates some sites' security policies.  It also presumably doesn't  
work at all for machines which are behind a firewall and use Kerberos  
only on an internal network.  And you couldn't use it for  
krb5_init_secure_context() since the information coming from that  
configuration isn't secure at all.

If it's a file on disk then supporting it involves having two  
locations for administrator files, both of which are presumably read  
by krb5_init_secure_context() as well as krb5_init_context().  If the  
public file could appear in different locations at different sites it  
would involve rebuilding the Kerberos libraries for each site since  
the search paths are hardcoded strings.  And note that the search  
paths should probably stay hardcoded strings since otherwise there  
are problems with using those config files with  
krb5_init_secure_context().

However, why do you need the final signifier for this?  When would it  
be necessary to *replace* a section in the global public file?  If  
the global public file contains errors you would presumably fix them  
and send your diffs back to the maintainers, right?  All the presence  
of the final signifier would do is to make it easy for sites to avoid  
updating the public file and instead just issue local corrections in  
their site config file.  Which would eventually defeat the purpose of  
having the public file in the first place.


> I think that maintaining a public repository of realm configuration
> data would be a worthwhile service.  As such I would like to see
> the finalize functionality be maintained.

I don't see how the final signifier is necessary for this, but I  
think the idea is a good one.   Although it would mean we would  
definitely need the shared profile support since reading the profile  
could become a very expensive operation.  And we would need to make  
sure the profile library was internally optimized to handle requests  
on these giant profiles.


--lxs

Alexandra Ellwood <lxs at mit.edu>
MIT Kerberos Development Team
<http://mit.edu/lxs/www>