Turning off hostname canonicalisation

[Alexandra Ellwood]

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  
>> that
>> simple.
>>
>
> 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].


--lxs

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