[krbdev.mit.edu #2634] GSSAPI should reset client principal in context when resetting the cache name

[Alexandra Ellwood via RT]

The internal krb5 context is as follows:

typedef struct _krb5_os_context {
	krb5_magic		magic;
	krb5_int32		time_offset;
	krb5_int32		usec_offset;
	krb5_int32		os_flags;
	char *			default_ccname;
	krb5_principal	default_ccprincipal;
} *krb5_os_context;

When resetting default_ccname in gss_init_sec_context() to pick up the new cache name, we 
need to also reset default_ccprincipal.  Currently GSS is calling krb5_cc_set_default_name() 
to reset default_ccname, and in most cases this also resets default_ccprincipal.  However, it 
doesn't when the following happens:
 
1) user has tickets in a cache with the default cache name
2) user calls gss_init_sec_context() (caching the cache name and principal)
3) user destroys the tickets
4) user calls gss_init_sec_context() again

In this case, krb5_cc_set_default_name() will not reset default_ccprincipal on the second call 
to GSS because the cache name is still be the same.  Here is the check from 
krb5_cc_set_default_name() which causes it to fail to reset default_ccprincipal:

	if (!os_ctx->default_ccname || (strcmp(os_ctx->default_ccname, new_name) != 0)) {
		/* the ccache changed... forget the old principal */
		if (os_ctx->default_ccprincipal)
			krb5_free_principal (context, os_ctx->default_ccprincipal);
		os_ctx->default_ccprincipal = 0;  /* we don't care until we use it */
	}

As you can see, the strcmp check will return 0 because default_ccname and new_name will 
both be the default cache name.  However this cache does not in fact have the principal 
default_ccprincipal stored in it because it is now empty.

I suspect that since krb5_cc_set_default_name() is called rather infrequently that the outer if 
statement should just be removed.  It seems like an unnecessary optimization.