krb5_libdefaults_string bug?

[Wyllys Ingersoll]

Sam Hartman wrote:
...
>     Wyllys> I dont think there is supposed to be a "REALM"
>     Wyllys> relationship in the [libdefaults] section, 
> 
> We agree; the current behavior is a bug.
> 
>     Wyllys> they are
>     Wyllys> supposed to be in the "[realms]" section of the krb5.conf
>     Wyllys> file.
> 
> 
> That's one possible interpretation.  Another is that this code should
> use the appdefaults interface for looking up realm-specific values.
> 
> The disadvantage of the appdefault interface is that it is for
> applications rather than the library.  However if PAM modules and
> other things that get initial tickets are going to have config options
> like get krb4 tickets in the appdefault interface then perhaps we
> should use that even within the library for this purpose.
> 
> So, I'd like to try and convince the list to come up with a consensus
> between realms section and appdefaults section and then we can accept
> the patch.

Is it OK to allow the parameter to be in both sections?  I've seen pam_krb5
code that first checks the [realms] and [libdefaults] sections and then
also looks in the [appdefaults] section (for "kinit") to see if there is an
application specific definition of the parameter(s) in question.

It might clear things up if some standard were established for
the correct order in which to search the sections and the precedence
level that each section has over another.

For example, does a parameter defined in [libdefaults] override the
same parameter found in the [realms] or [appdefaults] section?
It would seem to me that the definition that is found in the most "specific"
section (i.e. appdefaults is more specific than realms which is more
specific than libdefaults), would be used over the more general
definition, but I can see arguments for having it go the other way.

Just some thoughts for discussion.

-Wyllys