[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Turning off hostname canonicalisation
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, local preferences config
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@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
>> 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@jpl.nasa.gov, or firstname.lastname@example.org