Turning off hostname canonicalisation
lxs at MIT.EDU
Mon Sep 12 18:58:57 EDT 2005
On Sep 12, 2005, at 5:30 PM, Nicolas Williams wrote:
> On Mon, Sep 12, 2005 at 03:27:01PM -0400, Sam Hartman wrote:
>>>>>>> "Jeffrey" == Jeffrey Altman <jaltman at MIT.EDU> writes:
>> Jeffrey> The answer is 'no'. Settings in [appdefaults] are not
>> Jeffrey> for reading by the Kerberos libraries. They are for
>> Jeffrey> reading by the application.
>> It's not that simple. Or at least Sun has proposed making it not
> Er, well, not quite.
> *I* certainly prefer libdefaults over appdefaults, but I don't mind
> having both, with appdefaults being most specific.
> What Sun did mind was removal of appdefaults for kinit, which we
> had to
> add back in when we resync'ed to recent releases of MIT krb5. We can
> manage interface obsolescence and removal, but we have different rules
> and schedules than MIT; we'd prefer to coordinate the such as it might
> save us some effort.
Back when I started working for the Kerberos team we already had a
pretty good idea that [appdefaults] was a maintenance problem. Since
it was never really clear who was supposed to be using them, the
libraries, utility applications and various third-party applications
read them, sometimes even disagreeing on how to parse the values.
The user experience was inconsistent and confusing.
Obviously some of the pain was from weaknesses in the profile API and
our lack of documentation, but there was also a fundamental problem
that we had overloaded the meaning of the krb5.conf file. The
krb5.conf file should configure the behavior of the entire Kerberos
product, not individual applications that call into Kerberos. In
addition, if we encourage each application to contain code to parse
defaults like "ticket_lifetime", that's a maintenance problem. We
really want the parsing code in a single place in the library so the
behavior stays consistent between applications.
However, if we provide APIs to programmatically change the library
behavior on a krb5_context/GSSAPI context, then if an application
wants to deviate from the library preferences it can provide its own
preference (in its own configuration file) to override the default
behavior. That way it's obvious to the user that the preference is
for this application only, and only applications that need to
override the behavior contain any specialized code. This is what we
did on the Mac with the KLL. And yes, I realize that it's difficult
to add APIs to the GSSAPI, but I still think it's an easier problem
to solve than the long-term maintenance of [appdefaults].
Alexandra Ellwood <lxs at mit.edu>
MIT Kerberos Development Team
More information about the krbdev