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

[Greg Hudson]

On 5/23/19 5:36 PM, moore moore wrote:
> So, if I simply change the cred_usage to GSS_C_INITIATE ( it was BOTH),
> I get a slightly different error from gss_acquire_cred_from()
> 
> 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
> 
> So it is still looking for a keytab and I'm not sure how or why.

It's normal for gss_acquire_cred() to check the client keytab if it
doesn't find credentials in the ccache, so this trace message isn't the
reason why the operation is failing.  Look for ccache operations earlier
in the trace output.

> gss_store_cred_into() uses:
[...]
> [18869] 1558646982.419342: Storing proxyuser at TEST.COM ->
> krbtgt/TEST.COM at TEST.COM in MEMORY:clientuser1 at TEST.COM
> 
> Does that prove it is going into a MEMORY ccache? 

Yes.

The same process is handling the gss_store_cred_into() and the later
gss_acquire_cred_from(), right?

> I do have cred usage on the gss_store_cred_into() as BOTH also, but I
> also tried with GSS_C_INITIATE 

GSS_C_INITIATE is correct, but in the current implementation there isn't
a behavior difference.

> On the second point, I tried to store the "user_cred_handle" which is
> the output the call to gss_acquire_cred_impersonate_name() but that
> would not go into the store either.
> 
> There is nothing in the trace but the local logging error gives:
> 
> gss_store_cred_into: No credentials were supplied, or the credentials
> were unavailable or inaccessible 

That's GSS_S_NO_CRED.  By my reading of the code, gss_store_cred_into()
only returns that if its input_cred_handle is null (aka
GSS_C_NO_CREDENTIAL).  Can you double-check that you aren't passing a
null handle when you get this error?