Change in behavior for krb5_get_credentials()

Jeffrey Altman jaltman at MIT.EDU
Mon Apr 25 13:59:40 EDT 2005

I am writing to request feedback on a change I have committed to the cvs
regarding the behavior of the krb5_get_credentials() function.  In
current release
versions the krb5_get_credentials() function will return to the caller
errors generated
by a failed attempt to store the credential into the ccache.  This
behavior has the
side-effect of returning both a set of valid credentials which must be
freed by the
callers and an error code.

As it turns out, even within the MIT libraries we do not test for this
condition nor
is it documented anywhere.   Recently on kerberos at there was a
relating to gss-api problems with kfw when using the mslsa: ccache
type.  The gss
init_sec_context() call was failing because the credentials could not be
stored into
the read-only mslsa ccache.   This not only had the behavior of
preventing the
application from establishing a gss context with a perfectly valid set
of credentials
but also resulted in a memory leak because the krb5_get_credentials()
called failed
in error.

The change I have committed as RT ticket 3029 is to ignore any error codes
returned by a call to krb5_cc_store_creds() from within the
call.   The purpose of the krb5_get_credentials() call is to obtain a
valid set of
credentials.  The purpose of the krb5_cc_store_creds() call is to
optimize the
behavior for future calls.  As I see it, if the credentials are valid
that is all the
caller of krb5_get_credentials() should be concerned with.  Any KRB5_CC_xxxx
errors which were received would have to be ignored anyway by the caller.

If anyone sees a reason for treating this otherwise, please let us know.

Jeffrey Altman

More information about the krbdev mailing list