krb5_libdefaults_string bug?

Sam Hartman hartmans at MIT.EDU
Thu Sep 12 16:38:00 EDT 2002


>>>>> "Wyllys" == Wyllys Ingersoll <wyllys.ingersoll at sun.com> writes:

    Wyllys> I think there is a problem in the code that parses the
    Wyllys> krb5.conf file for realm-specific options...

    Wyllys> file: get_in_tkt.c routine: krb5_libdefault_string

    Wyllys> Problem - The routine never looks in the [realm] section
    Wyllys> to find the associated option/value relationship for the
    Wyllys> realm specified by the caller.  Even the comment is wrong.

    Wyllys>      /* * Try number one: * * [libdefaults] * REALM = { *
    Wyllys> option = <boolean> * } */

    Wyllys> Shouldn't this be: /* * [realms] * REALM = { * option =
    Wyllys> <boolean> * } */ ??

    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.




More information about the krbdev mailing list