Query regarding the ticket options passed by an application

[Sam Hartman]

>>>>> "Datar," == Datar, Ashutosh Anil <ashutosh.datar at hp.com> writes:

    Datar,> Hi, Can someone provide the inputs on this?  Is the
    Datar,> current behavior for options 'forwardable' and 'proxiable'
    Datar,> expected one?

    Datar,> Thanks and Regards, Ashutosh

    Datar,> ________________________________ From: Datar, Ashutosh
    Datar,> Anil Sent: Monday, October 20, 2008 3:04 PM To:
    Datar,> krbdev at mit.edu Cc: PDL-krbteam Subject: Query regarding
    Datar,> the ticket options passed set an application

    Datar,> Hi,

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

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

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

    Datar,> ====================================================================
    Datar,> Options are set in krb5int_populate_gic_opt () like:

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

    Datar,>      Functions krb5_get_init_creds sets the options as
    Datar,> follows:

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

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

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

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

    Datar,> Thanks and Regards, Ashutosh
    Datar,> _______________________________________________ krbdev
    Datar,> mailing list krbdev at mit.edu
    Datar,> https://mailman.mit.edu/mailman/listinfo/krbdev


Yes, it is expected that krb5_get_in_tkt_with_password does not
respect libdefault values.  It's an older API.  Use
krb5_get_init_creds_password if you want libdefault values to be
respected.


A PAM module that is using that old API seems highly unfortunate today.