gss_store_cred_into() and gss_acquire_cred_from() on a client specific basis

[Greg Hudson]

On 5/24/19 12:19 PM, moore moore wrote:
> gss_acquire_cred_from() for gss_name:u:clientuser1 at TEST.COM, 
>  store:0x6ddf68, elem:0x6ddf78
> 
> [28197] 1558713187.312227: Retrieving clientuser1 at TEST.COM from
> FILE:/krb5/dest/var/krb5/user/0/client.keytab (vno 0, enctype 0) with
> result: 2/Key table file '/krb5/dest/var/krb5/user/0/client.keytab' not
> found

Oh, I see, it's the only trace log message.  It seems we don't generate
any trace logs when scanning the ccache, so there's nothing in the trace
log to verify what ccache gss_acquire_cred_from() is trying to use.

Since the trace logs aren't helpful in this case, I would suggest adding
debugging code to verify what values are contained within store, not
just that it has the same pointer value.  If you're in a position to
step through the libgssapi_krb5 code, you could alternatively see what's
happening inside scan_ccache().

Separately, it occurs to me that if the same process is handling the
reauths, you could just save the GSS cred handle and not bother with
gss_store_cred_into/gss_acquire_cred_from.  You'd have to create your
own table mapping client names to GSS cred handles to make this work,
but there would be fewer GSS and krb5 operations to worry about.  Just
another option.