Change in behavior for krb5_get_credentials()

[Jeffrey Altman]

John Hascall wrote:
> I think you're making this purposefully abstruse.
> 
> From:
>             if ((rv2 = krb5_cc_store_cred(context, ccache, tgts[i]))) {
>                 retval = rv2;
>                 break;
>             }
> 
> to:
>             if ((rv2 = krb5_cc_store_cred(context, ccache, tgts[i]))) {
>                 if (!(options & KRB5_GC_IGNORE_STORE_ERRORS)) {
>                     retval = rv2;
>                     break;
> 		}
>             }
> 
> (and similarly one other place)
> 
> Or alternatively, you could just tell people to check
> out_creds even if they get an error return -- no library
> change needed.

John:

There is no documentation for this api.  Therefore it is important that
the changes to its behavior have minimal impact.   It is unfortunate but
no one ever considered when designing for credential cache use that one
day we might have to deal with a read-only credential cache.  The types
of changes which cause me concern are:

(1) those that cause applications to fail to perform authentication

(2) those that result in memory leaks

Now it is clear that users of gss-api which calls krb5_get_credentials()
are having their applications fail to authenticate when using the MSLSA:
ccache on Windows if the Windows LSA is not properly configured with
KSETUP.  In this case the krb5_get_credentials() returns
KRB5_CC_READONLY and the gss_init_sec_context() call fails when it
should not.   None of the example code says that users should check the
contents of *out_creds or even set it to NULL prior to making a call to
krb5_get_credentials() so it is a bit late to make that recommendation
now.  It is important that if krb5_get_credentials() returns a valid
credential that the applications continue to use it.  At the moment that
can only be guarranteed if the krb5_cc_store_creds() errors are ignored.

There is strong evidence to indicate that applications are leaking
memory because when krb5_get_credentials() returns an error code that
apps fail to free the credentials that are returned.  By hiding the
store creds errors unless asked for we can prevent this as well.  If we
don't provide a function which allows an application to know what
krb5_get_credentials considers a store creds error to be, we will run
into exactly the same problem the next time we have to add a new error
code that can be returned by krb5_cc_store_creds().

Adding flags is fine but they need to be flags which prevent the
majority of applications from either leaking memory or failing to succeed.

Jeffrey Altman