I've been reading though a lot of GSSAPI code of late, in an exercise to
remove gssapi_krb5_context, or where this is impossible, to make it
'state machine safe', by having it set to the last user krb5_context in
use (presuming you don't switch gssapi contexts between an erroring
function and the error display, for example).
This is also a good way for me to tour the GSSAPI library...
Anyway, I'm trying to understand why the GSSAPI code needs to violate
the abstraction layer of keytab types in this code:
OM_uint32 gss_release_cred
(OM_uint32 * minor_status,
gss_cred_id_t * cred_handle
)
{
...
const krb5_cc_ops *ops;
ops = krb5_cc_get_ops(gssapi_krb5_context, (*cred_handle)->ccache);
if (ops == &krb5_mcc_ops)
krb5_cc_destroy(gssapi_krb5_context, (*cred_handle)->ccache);
else
krb5_cc_close(gssapi_krb5_context, (*cred_handle)->ccache);
}
Why does the GSSAPI layer care about what type of ccache it is? I see
that the object in-memory is reference counted, so shouldn't that be
handled inside krb5_cc_close() (which seems to try and clean up some
memory, but not all...)?
Andrew Bartlett
--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Student Network Administrator, Hawker College http://hawkerc.net
This is a digitally signed message part