(Final?) krb5.Conf Lexer/Parser Proposal

[Alexandra Ellwood]

On Jan 5, 2006, at 9:26 AM, Jeffrey Altman wrote:

> Joseph Calzaretta wrote:
>> Ted,
>>
>> Thanks for your input.  I think we do understand why the final
>> signifier was implemented, but the Kerberos team thought it wasn't
>> worth supporting.  We might want to review this decision, especially
>> if we discover that a lot of existing profile config files are using
>> it.  Thanks again!
>>
>> --Joe
>>
>> Joe Calzaretta
>> Software Development & Integration Team
>> MIT Information Services & Technology
>
> If we want to continue to support chaining of configuration files
> then I think it must be supported.
>
> The configuration editor in KFW does not generate the "final  
> signifier"
> on sections because there is rarely ever more a single krb5.conf file
> and it would be unclear whether or not the user preferences should be
> treated as an addition to the administrative defaults or an addition
> to them.  Right now there simply isn't a good UI for managing this
> distinction.


Chaining of configuration files is perfectly useful without the final  
signifier since it lets the user add their own realms to the realm  
configuration.  As Kerberos becomes more wide-spread, sites will  
frequently not list all Kerberos realms that any user might want to  
use in the system configuration file.  Having a user configuration  
file means that the user will not have to petition to their site  
administrator to have, say, their bank's Kerberos realm added to the  
system configuration.

The final signifier isn't even necessary to override a single-value  
tag.  You can just put it in your user config file.  Since the user's  
config file is read first, the user's tags will appear first in the  
(sub)section.  Currently the krb5 libraries only look for the first  
instance of a single-value tag, so they will consistently use the  
user's tag instead of the system one.  I can't see any reason to  
change this behavior and it could be confusing if we did.

And if you want to change large portions of the system config file,  
you can just copy, edit and use the KRB5_CONFIG environment variable  
to override it completely.  This is even possible on Mac OS X via  
~/.MacOSX/environment.plist, which affects all applications,  
including GUI ones.


So what exactly does the final signifier gain us?

Now maybe I'm missing something obvious, but the only case I can  
think of where you would want to use the final signifier is if you  
want to *replace* an entire sub-section or a multi-value tag such as  
the KDC tags for a single realm.  However, the only reason I can  
think of why you would want to do this is for testing.  If there is a  
defective realm configuration in your system config file, you should  
be complaining to your sysadmin instead of kludging around it.  And  
if you're testing or temporarily working around a defective  
configuration, copying the system configuration and using KRB5_CONFIG  
should be an adequate solution.


Even with the final signifier it's not like we'd be supporting  
everything the user would like to do.  The user might like to add a  
tag to the end of a list of multi-valued tags.  Since the user's tags  
always come first in the merged configuration, this is impossible  
without replacing the entire section in the user's config file or  
using KRB5_CONFIG.


I'm also concerned about the support issues of having a final  
signifier.  The syntax seems sufficiently subtle that site help desks  
would have trouble debugging busted configurations.  Users are  
already in the habit of cut and pasting config file lines from random  
locations and not even bothering to check if the lines do anything  
(eg: "ticket_lifetime = 600").  Imagine the nightmare support calls  
which could result from accidentally copying lines containing a '*'.



--lxs

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