Turning off hostname canonicalisation

Henry B. Hotz hotz at jpl.nasa.gov
Mon Sep 12 19:34:00 EDT 2005

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

More information about the krbdev mailing list