(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: <18.104.22.168.2.20060105085947.036e0710 at hesiod>
> Content-Type: text/plain; charset="us-ascii"; format=flowed
> 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 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
>> leave to others to decide, but in case it wasn't understood why it
>> originally added, this might be useful historical perspective.
>> - Ted
More information about the krbdev