[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

init_sec_context.c / profile reading



Disclaimer: I know little about gssapi and not much about the intended
behavior of options etc

It seems that in heimdal it's somewhat difficult to deal with options from
krb5.conf in a non-ad-hoc manner.  For instance, kinit uses
krb5_get_init_creds_password after resolving the default options with
krb5_get_init_creds_opt_set_default_flags .  This works well because
krb5_g_i_c_p calls the static get_init_creds_common which munges the
krb5_get_init_creds_opt structure into the krb5_kdc_flags structure that you
actually need to acquire credentials.  However, not everything calls into
the get_init_creds calls...for instance gssapi in
init_sec_context.c:do_delegation simply sets the forwarded and forwardable
bits in the kdc flags itself and leaves it at that before calling
krb5_get_forwarded_creds which doesn't do anything more with the flags:

    fwd_flags.i = 0;
    fwd_flags.b.forwarded = 1;
    fwd_flags.b.forwardable = 1;
...
    kret = krb5_get_forwarded_creds(gssapi_krb5_context,

This means that unfortunately if you want renewable and proxiable tickets by
default on a machine you're out of luck - the gssapi code doesn't give you a
way as far as I can tell to specify this (and in a related vein it doesn't
seem to me that forwarded tickets should automatically be marked
forwardable).  Instead it seems like the gssapi code should be able to do
something like this:

    krb5_get_init_creds_opt opt;
    krb5_kdc_flags fwd_flags;

    krb5_get_init_creds_opt_init(&opt);
    krb5_get_init_creds_opt_set_default_flags(gssapi_krb5_context,
                                              "gssapi",
                                              creds.client->realm,
                                              &opt);
    krb5_munge_opts_to_flags(&opt, &fwd_flags);
    fwd_flags.b.forwarded = 1;

where krb5_munge_opts_to_flags basically does much of what
init_creds_pw.c:get_init_creds_common currently does.  Comments?  It could
be that I'm missing something but the current set up seems to require a lot
of duplicate effort for any code that wants to initialize ticket options
from krb5.conf.

-- 

..ooOO chris@chiappa.net              | My opinions are my own  OOoo..
..ooOO chris.chiappa@oracle.com       | and certainly not those OOoo..
..ooOO http://www.chiappa.net/~chris/ | of my employer          OOoo..