Query regarding the ticket options passed set an application

Datar, Ashutosh Anil ashutosh.datar at hp.com
Mon Oct 20 05:34:17 EDT 2008


Hi,

I had a query regarding the treatment given to options ("forwardable" or "proxiable") passed by an application through the call krb5_get_in_tkt_with_password ().

What we observed while working on PAM Kerberos (libpam_krb5) is that, if an option is not mentioned by the PAM configuration file, then the mentioned function (krb5_get_in_tkt_with_password) sets it to "false".
Now that the option is set to something, the libdefault value for that option won't be considered at all. Because, the code in function krb5_get_init_creds () checks to see if the option is already set (to something, be it false or true) and if set, then takes the previously specified value.

This makes a difference when no option is specified in PAM but the same option is set to true in Kerberos configuration; because in this case, the Kerberos option will be totally ignored.

====================================================================
     Options are set in krb5int_populate_gic_opt () like:

          :
     if (options&KDC_OPT_FORWARDABLE)
         krb5_get_init_creds_opt_set_forwardable(opt, 1);
     else krb5_get_init_creds_opt_set_forwardable(opt, 0);
     if (options&KDC_OPT_PROXIABLE)
         krb5_get_init_creds_opt_set_proxiable(opt, 1);
     else krb5_get_init_creds_opt_set_proxiable(opt, 0);
          :

     Functions krb5_get_init_creds sets the options as follows:

     if (options && (options->flags & KRB5_GET_INIT_CREDS_OPT_FORWARDABLE))
        tempint = options->forwardable;
     else if ((ret = krb5_libdefault_boolean(context, &client->realm,
                                            "forwardable", &tempint)) == 0)
            ;
     else
        tempint = 0;
     if (tempint)
        request.kdc_options |= KDC_OPT_FORWARDABLE;
====================================================================

Now the question is if there is any specific reason behind keeping it like this?
Because, the "libdefaults" in krb5.conf being the default options for libkrb5 library, an application can override them but in case an application doesn't mention about the option, it can always refer to the default value set for that option in Kerberos configuration.
Also, the default values of these options being "false", if none of the configurations (application and Kerberos) are mentioning about an option, it will not affect the application logic also.

While searching online, I could see few of the other implementations, where the specific options from application configuration (PAM here) take preference but otherwise the defaults from krb5.conf will always be considered.

Can you please let me know if this is the expected behavior and if yes, why?

Thanks and Regards,
Ashutosh



More information about the krbdev mailing list