(Final?) krb5.Conf Lexer/Parser Proposal

Henry B. Hotz hotz at jpl.nasa.gov
Thu Jan 5 13:02:14 EST 2006

I'll second (or 3rd or 4th) the opinion that the finalizer goes with  
supporting chained config files.  Do both or neither.

Like Jeffrey, I disagree with the claim that only Unix uses chained  
config files.  On MacOS X you can have stuff in ~/Library/Preferences  
as well as [/System]/Library/Preferences.  Mac and PC users are less  
likely to be sophisticated enough to use the functionality when it's  
supported, but it's still desired/used.

It might be desirable to add support for a "negation" operator so you  
could say "use the standard kdc's except for this one".  I recognize  
that such an operator would be relatively expensive to implement, so  
I won't put it in the same class as the finalizer.

On Jan 5, 2006, at 8:48 AM, krbdev-request at mit.edu wrote:

> Date: Thu, 05 Jan 2006 09:19:16 -0500
> From: Joseph Calzaretta <saltine at MIT.EDU>
> Subject: Re: (Final?) krb5.Conf Lexer/Parser Proposal
> To: "Theodore Ts'o" <tytso at MIT.EDU>
> Cc: krbdev at mit.edu
> Message-ID: < at hesiod>
> Content-Type: text/plain; charset="us-ascii"; format=flowed
> 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
> At 04:12 AM 1/5/2006, Theodore Ts'o wrote:
>> You understand why the "final" signifier was implemented, right?  The
>> idea was to be able to provide the ability to have a user's ~/.krb5rc
>> override portions of /etc/krb5.conf.  So if KRB5_CONFIG is set to
>> ~/.krb5rc:/etc/krb5.conf, then it is possible to override an entire
>> stanza by using the finalizer.
>> Is anyone actually using this?  I can't answer that question; but it
>> is useful functionality.  Whether or not it is worth preserving I  
>> will
>> leave to others to decide, but in case it wasn't understood why it  
>> was
>> originally added, this might be useful historical perspective.
>>                                                 - Ted

More information about the krbdev mailing list