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

gss_release_cred(), and memory ccache

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);
	    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