Turning off hostname canonicalisation

[Henry B. Hotz]

Clearly, I've opened a can of worms.  *sigh*  The universe should be  
simpler than this.

In an ideal world, where all the possibilities exist I think the  
priority for an option setting should be:

Program, hard-coded
Program, local preferences config
[appdefaults] program={REALM={...}}
[appdefaults] program={...}
[appdefaults] REALM={...}
[appdefaults] ...
[libdefaults] REALM={...}
[libdefaults] ...
library, hard-coded

Of course if all the [appdefaults] possibilities exist, then the  
[libdefaults] possibilities are redundant, provided it's well-known and  
consistent that the option isn't in [libdefaults].  Ticket renew  
lifetime comes to mind as an issue.

Just my offhand opinion.  I'm not trying to torque anyone around.

On Sep 12, 2005, at 3:58 PM, Alexandra Ellwood wrote:

> 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.
. . .
> 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].
------------------------------------------------------------------------ 
----
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu