Change in behavior for krb5_get_credentials()

[Jeffrey Altman]

I am writing to request feedback on a change I have committed to the cvs
head
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 mit.edu there was a
discussion
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
krb5_get_credentials()
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