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

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

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

moore moore
Hello,I'm using kerberos lib 1.16.1
I have a intermediary process acting as a proxy between clients and kerberized services.High level outline of the processing is as follows:- TGT is granted for impersonator representing the proxy. This principal is configured for delegation on KDC. - gss_acquire_cred() is used to acquire handle to impersonator- gss_acquire_cred_impersonate_name() is used to get "proxy credential" for Constrained delegation (S4U)- this is all very similar to the test code in t_s4u.c which ends up calling constrained_delegate()and gss_init_sec_context() with delegated_cred_handle 
All this works good and I can see in log:Creating authenticator for [hidden email] -> http/[hidden email], seqnum 341751283, subkey aes256-cts/143B, session key aes256-cts/99D6
I can see that the authenticator is built from call to krb5_mk_req_extended()The AP request is then sent from proxy to the service over SPNEGO.
I want to cache credential so that I can reuse for reauthentication 401 challenges from the service.

So I used: gss_store_cred_into() to store the delegated_cred_handle.When I do test (after the gss_store_cred_into()), with gss_acquire_cred_from() and then check_ticket_count(), it tells me I have the 3 creds.I think that this is correct.
"store" and "elem" are handles that I store in an application level session cache on a per clientuser basis.So each client SHOULD have their own to reference.
ccname is something like [hidden email] is the "delegated_cred_handle" as in the code associated with constrained_delegate() function. (like in  t_s4u.c) 

        store->count = 1;        store->elements = elem;        elem->key = "ccache";        elem->value = ccname;
        major = gss_store_cred_into(&minor,                                    cred,                                    GSS_C_BOTH /*GSS_C_INITIATE*/,                                                                                                                                            &mech_krb5,                                                                                                                                                1, //overwrite                                                                                                                                                    0,                                    store,                                    NULL,                                    NULL);

And based on below, I can see the MEMORY:MY_CRED_STORE store being initialised.  [24024] 1558607679.670443: TGS reply is for [hidden email] -> http/[hidden email] with session key aes256-cts/BFA1[24024] 1558607679.670444: TGS request result: 0/Success[24024] 1558607679.670445: Received creds for desired service http/[hidden email][24024] 1558607679.670446: Storing [hidden email] -> http/[hidden email] in MEMORY:lFUNvFV[24024] 1558607679.670448: Creating authenticator for [hidden email] -> http/[hidden email], seqnum 455078816, subkey aes256-cts/190C, session key aes256-cts/BFA1[24024] 1558607679.670454: Initializing MEMORY:MY_CRED_STORE with default princ [hidden email][24024] 1558607679.670455: Storing [hidden email] -> http/[hidden email] in MEMORY:MY_CRED_STORE[24024] 1558607679.670456: Storing [hidden email] -> [hidden email] in MEMORY:MY_CRED_STORE[24024] 1558607679.670457: Storing [hidden email] -> krb5_ccache_conf_data/proxy_impersonator@X-CACHECONF: in MEMORY:MY_CRED_STORE[24024] 1558607679.670458: Storing [hidden email] -> krb5_ccache_conf_data/pa_type/krbtgt\/TEST.COM\@TEST.COM@X-CACHECONF: in MEMORY:MY_CRED_STORE[24024] 1558607679.670459: Storing [hidden email] -> krbtgt/[hidden email] in MEMORY:MY_CRED_STORE[24024] 1558607679.670462: Destroying ccache MEMORY:lFUNvFV[24024] 1558607679.670464: Destroying ccache MEMORY:we3p14b

When a 401 reauthentication comes back from the kerberised server - I do the following:
major = gss_acquire_cred_from(&minor,                              bname,                              0,                              mechs,                              cred_usage,                              &store,   // store used in the call to gss_store_cred_into() above.                               &delegated_cred_handle,                              NULL,                              NULL);if(check_gsserr("gss_acquire_cred_from", major, minor)){                printf("gss_acquire_cred_from error major :%d, minor:%d",major, minor);}else{ constrained_delegate(delegated_cred_handle, impersonator_cred_handle, target, &ticket_desc);}
And this generates new authenticator so that I can use over SPNEGO between proxy and server. 
[24024] 1558607699.14566: Getting credentials [hidden email] -> http/[hidden email] using ccache MEMORY:MY_CRED_STORE[24024] 1558607699.14567: Retrieving [hidden email] -> http/[hidden email] from MEMORY:MY_CRED_STORE with result: 0/Success[24024] 1558607699.14569: Creating authenticator for [hidden email] -> http/[hidden email], seqnum 8453532, subkey aes256-cts/94CE, session key aes256-cts/BFA1[24024] 1558607699.14589: Getting credentials [hidden email] -> http/[hidden email] using ccache MEMORY:MY_CRED_STORE[24024] 1558607699.14590: Retrieving [hidden email] -> http/[hidden email] from MEMORY:MY_CRED_STORE with result: 0/Success[24024] 1558607699.14592: Creating authenticator for [hidden email] -> http/[hidden email], seqnum 690537534, subkey aes256-cts/EF50, session key aes256-cts/BFA1

So all this is good and avoids TGS round trips to the KDC.

However, when a different client logs in, clientuser2, the service tickets get polluted.Where clientuser1 can get access to clientuser2 backend server session.
I then noticed that the way I imported bname ( desired_name ) input parameter to gss_acquire_cred_from() was wrong.
So I tried import_name() with "u:[hidden email]" which should give nametype of GSS_C_NT_USER_NAME for gss_import_name.But that makes gss_acquire_cred_from() fail with:
gss_acquire_cred_from: Unspecified GSS failure.  Minor code may provide more information gss_acquire_cred_from: SPNEGO cannot find mechanisms to negotiate gss_acquire_cred_from error major :851968, minor:100005

I think I need to be able to hold a fleet of credentials that are specific to the clients, which is what I have.ie. store and elem in an application level client specific session cache, so that I can reuse that specific cred to generate new authenticator for the clientuser to the service.But somehow it seems that the "store" is not exclusive? 
Am I creating the store at the correct level, storing the correct cred? ie. delegated_cred_handle  Why does it get polluted with credential for different user?
I have tried to create store with clientuser specific name also.like : MEMORY:[hidden email] while the store into still worked, acquire_from failed with:gss_acquire_cred_from: SPNEGO cannot find mechanisms to negotiate gss_acquire_cred_from error major :851968, minor:100005
But I dont see a way to use ccache name anyways to reference the store subsequently?
Any thoughts most welcome on what the recommended/best approach would be?
Thank you kindly. 




_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

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

Greg Hudson
On 5/23/19 8:04 AM, moore moore wrote:
> I have tried to create store with clientuser specific name also.like : MEMORY:[hidden email]
> And while the store into still worked, acquire_from failed with:
> gss_acquire_cred_from: SPNEGO cannot find mechanisms to negotiate
> But I dont see a way to use ccache name anyways to reference the store subsequently?

This is the right approach; you need client-specific ccache names to
store the proxy creds.

gss_acquire_cred_from() accepts a cred_store parameter just like
gss_store_cred_into(), and it must contain the same (per-client) ccache
value to find the correct creds.

The SPNEGO error message isn't very specific.  You could use trace logs
to try to figure out why acquiring krb5 creds doesn't work, or you could
(temporarily, for debugging purposes) try acquiring krb5 creds instead
of SPNEGO creds.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

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

moore moore
 Thanks for the reply and info Greg
Looks like the error in the trace on call to gss_acquire_cred_from() is:[31361] 1558626925.414958: Retrieving [hidden email] from FILE:/etc/krb5.keytab (vno 0, enctype 0) with result: -1765328203/No key table entry found for [hidden email]
Why would it be looking in FILE: cache? when using the "store" handle input that was used for gss_store_cred_into()? 
Also when you say, proxy cred is the correct cred to cache, I have been caching the "delegated_cred_handle" as I wanted to retrieve that and use as the delegated_cred_handle input into next call of gss_init_sec_context(). Is that thinking wrong? and it just works by accident in single clientuser case?
Based on what you are saying, it should be the impersonator_cred_handle?
I quickly tried a call to gss_store_cred_into() with the impersonator_cred_handle and it failed with:
gss_store_cred_into: No credentials were supplied, or the credentials were unavailable or inaccessible gss_store_cred_into: Unknown error gss_store_cred_into failed with major:458752 and minor:0 
All that is in the trace for that specific all to gss_store_cred_into() with the impersonator_cred_handle is:[23610] 1558630947.630858: Destroying ccache MEMORY:6EupW9M[23610] 1558630947.630860: Destroying ccache MEMORY:P3uB2zU
The handle should be still valid. Basically calling in the same place as storing the delegated_cred_handle.After the successfull initial call to constrained_delegate() and before calling the release routines.        gss_release_cred(&minor, &impersonator_cred_handle);        gss_release_cred(&minor, &delegated_cred_handle);        gss_release_cred(&minor, &user_cred_handle);
I;m a bit handicapped with debug as there is no debugging gdb capabilities on the run time machine :-(So really appreciate your insight.












    On Thursday 23 May 2019, 16:27:06 GMT+1, Greg Hudson <[hidden email]> wrote:  
 
 On 5/23/19 8:04 AM, moore moore wrote:
> I have tried to create store with clientuser specific name also.like : MEMORY:[hidden email]
> And while the store into still worked, acquire_from failed with:
> gss_acquire_cred_from: SPNEGO cannot find mechanisms to negotiate
> But I dont see a way to use ccache name anyways to reference the store subsequently?

This is the right approach; you need client-specific ccache names to
store the proxy creds.

gss_acquire_cred_from() accepts a cred_store parameter just like
gss_store_cred_into(), and it must contain the same (per-client) ccache
value to find the correct creds.

The SPNEGO error message isn't very specific.  You could use trace logs
to try to figure out why acquiring krb5 creds doesn't work, or you could
(temporarily, for debugging purposes) try acquiring krb5 creds instead
of SPNEGO creds.
 
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

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

Greg Hudson
On 5/23/19 1:15 PM, moore moore wrote:
> Thanks for the reply and info Greg
>
> Looks like the error in the trace on call to gss_acquire_cred_from() is:
> [31361] 1558626925.414958: Retrieving [hidden email] from
> FILE:/etc/krb5.keytab (vno 0, enctype 0) with result: -1765328203/No key
> table entry found for [hidden email]
>
> Why would it be looking in FILE: cache? when using the "store" handle
> input that was used for gss_store_cred_into()?

That's not a ccache, that's a keytab.  Make sure you are passing
GSS_C_INITIATE as the cred_usage to gss_acquire_cred_from() for this
call, not GSS_C_ACCEPT or GSS_C_BOTH.

> Also when you say, proxy cred is the correct cred to cache, I have been
> caching the "delegated_cred_handle" as I wanted to retrieve that and use
> as the delegated_cred_handle input into next call
> of gss_init_sec_context(). Is that thinking wrong? and it just works by
> accident in single clientuser case?

In t_s4u.c, the call to init_accept_sec_context() is unnecessary -- it
helps with test coverage and allows some extra information to be
displayed, but you can just use the proxy cred (user_cred_handle in
t_s4u.c) as input to the constrained delegation gss_init_sec_context() call.

If you do the init/accept round trip after the S4U2Self request, there
is functionally, there is no difference between storing or using the
proxy cred or delegated cred handles.

> Based on what you are saying, it should be the impersonator_cred_handle?

No, the impersonator_cred_handle represents the intermediate service.
You need the output of gss_acquire_cred_impersonate_name().
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

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

moore moore
 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 [hidden email] 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.
gss_store_cred_into() uses:

store->count = 1;store->elements = elem;elem->key = "ccache";elem->value = ccname;
where ccname is: MEMORY:[hidden email]
Is that correct? 
This the output from log:[18869] 1558646982.419337: Initializing MEMORY:[hidden email] with default princ [hidden email][18869] 1558646982.419338: Storing [hidden email] -> http/[hidden email] in MEMORY:[hidden email][18869] 1558646982.419339: Storing [hidden email] -> [hidden email] in MEMORY:[hidden email][18869] 1558646982.419340: Storing [hidden email] -> krb5_ccache_conf_data/proxy_impersonator@X-CACHECONF: in MEMORY:[hidden email][18869] 1558646982.419341: Storing [hidden email] -> krb5_ccache_conf_data/pa_type/krbtgt\/TEST.COM\@TEST.COM@X-CACHECONF: in MEMORY:[hidden email][18869] 1558646982.419342: Storing [hidden email] -> krbtgt/[hidden email] in MEMORY:[hidden email]
Does that prove it is going into a MEMORY ccache? 
I do have cred usage on the gss_store_cred_into() as BOTH also, but I also tried with GSS_C_INITIATE 
and the gss_acquire_cred_from() failed with the same error as above ( looking for a keytab)



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 gss_store_cred_into: Unknown error gss_store_cred_into failed with major:458752 and minor:0
So the only cred handle that that will store for me is the "delegated_cred_handle"!

Thanks for your help. 
    On Thursday 23 May 2019, 19:47:07 GMT+1, Greg Hudson <[hidden email]> wrote:  
 
 On 5/23/19 1:15 PM, moore moore wrote:
> Thanks for the reply and info Greg
>
> Looks like the error in the trace on call to gss_acquire_cred_from() is:
> [31361] 1558626925.414958: Retrieving [hidden email] from
> FILE:/etc/krb5.keytab (vno 0, enctype 0) with result: -1765328203/No key
> table entry found for [hidden email]
>
> Why would it be looking in FILE: cache? when using the "store" handle
> input that was used for gss_store_cred_into()?

That's not a ccache, that's a keytab.  Make sure you are passing
GSS_C_INITIATE as the cred_usage to gss_acquire_cred_from() for this
call, not GSS_C_ACCEPT or GSS_C_BOTH.

> Also when you say, proxy cred is the correct cred to cache, I have been
> caching the "delegated_cred_handle" as I wanted to retrieve that and use
> as the delegated_cred_handle input into next call
> of gss_init_sec_context(). Is that thinking wrong? and it just works by
> accident in single clientuser case?

In t_s4u.c, the call to init_accept_sec_context() is unnecessary -- it
helps with test coverage and allows some extra information to be
displayed, but you can just use the proxy cred (user_cred_handle in
t_s4u.c) as input to the constrained delegation gss_init_sec_context() call.

If you do the init/accept round trip after the S4U2Self request, there
is functionally, there is no difference between storing or using the
proxy cred or delegated cred handles.

> Based on what you are saying, it should be the impersonator_cred_handle?

No, the impersonator_cred_handle represents the intermediate service.
You need the output of gss_acquire_cred_impersonate_name().
 
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: 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 [hidden email] 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 [hidden email] ->
> krbtgt/[hidden email] in MEMORY:[hidden email]
>
> 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?

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

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

moore moore
 Yes, absolutely, the same process is handling the gss_store_cred_into() and the latergss_acquire_cred_from().

What is strange is that, (alluding to my original message),When the store is initialised with: MEMORY:MY_CRED_STORE
[28396] 1558699329.882132: Initializing MEMORY:MY_CRED_STORE with default princ [hidden email][28396] 1558699329.882133: Storing [hidden email] -> http/[hidden email] in MEMORY:MY_CRED_STORE[28396] 1558699329.882134: Storing [hidden email] -> [hidden email] in MEMORY:MY_CRED_STORE[28396] 1558699329.882135: Storing [hidden email] -> krb5_ccache_conf_data/proxy_impersonator@X-CACHECONF: in MEMORY:MY_CRED_STORE[28396] 1558699329.882136: Storing [hidden email] -> krb5_ccache_conf_data/pa_type/krbtgt\/TEST.COM\@TEST.COM@X-CACHECONF: in MEMORY:MY_CRED_STORE[28396] 1558699329.882137: Storing [hidden email] -> krbtgt/[hidden email] in MEMORY:MY_CRED_STORE
The process pid is 28396
Subsequently (only a second later) a call to gss_acquire_cred_from() will result in:
[28396] 1558699330.991814: Getting credentials [hidden email] -> http/[hidden email] using ccache MEMORY:MY_CRED_STORE[28396] 1558699330.991815: Retrieving [hidden email] -> http/[hidden email] from MEMORY:MY_CRED_STORE with result: 0/Success[28396] 1558699330.991817: Creating authenticator for [hidden email] -> http/[hidden email], seqnum 362610509, subkey aes256-cts/D0D8, session key aes256-cts/F87B

So that appears to work exactly as I require. Until a another user logs in. and I guess there is a behind the scenes use of the MEMORY:MY_CRED_STORE??



So when I change the cache name to be unique to the clientuserie. like this: MEMORY:[hidden email]
The store init still looks OK.

[10940] 1558700394.80052: Initializing MEMORY:[hidden email] with default princ [hidden email][10940] 1558700394.80053: Storing [hidden email] -> http/[hidden email] in MEMORY:[hidden email][10940] 1558700394.80054: Storing [hidden email] -> [hidden email] in MEMORY:[hidden email][10940] 1558700394.80055: Storing [hidden email] -> krb5_ccache_conf_data/proxy_impersonator@X-CACHECONF: in MEMORY:[hidden email][10940] 1558700394.80056: Storing [hidden email] -> krb5_ccache_conf_data/pa_type/krbtgt\/TEST.COM\@TEST.COM@X-CACHECONF: in MEMORY:[hidden email][10940] 1558700394.80057: Storing [hidden email] -> krbtgt/[hidden email] in MEMORY:[hidden email]

But the subsequent call to gss_acquire_cred_from() ( same code path as above ) fails with:

[10940] 1558700394.80066: Retrieving [hidden email] 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
You can see is it same process pid also: 10940 for that test. 

This is the call to store_into is like:
        store->count = 1;        store->elements = elem;        elem->key = "ccache";        elem->value = ccname;

major = gss_store_cred_into(&minor,                            cred,                            GSS_C_INITIATE,                                                                                                                                &mech_krb5,                                  1, //overwrite                                0, //default cred                                 store, // pointer to a gss_key_value_set_desc                            NULL,                            NULL);

And acquire:
gss_name_t gss_name;
gss_name = import_name(name); // name like u:[hidden email]

major = gss_acquire_cred_from(&minor,                                      gss_name,                                                                                                                                                0,                                      mechs,                                        //&mechset_krb5,                                           //&mechset_spnego,                                       GSS_C_INITIATE, //cred_usage,                                                   &store,                                      &delegated_cred_handle,                                      NULL,                                      NULL);

With mech as "&mech_krb5", I get nothing in the trace.
But the following local logs from check_gsserr()gss_acquire_cred_from: An unsupported mechanism was requested gss_acquire_cred_from: Unknown error gss_acquire_cred_from error major :65536, minor:0
With mechset_spnego, I get:[10940] 1558700394.80066: Retrieving [hidden email] 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
and check_gsserr()gss_acquire_cred_from: Unspecified GSS failure.  Minor code may provide more information gss_acquire_cred_from: SPNEGO cannot find mechanisms to negotiate gss_acquire_cred_from error major :851968, minor:100005



So why is the there a difference on gss_acquire_cred_from() betweenMEMORY:MY_CRED_STORE with a ccname of "[hidden email]"
andMEMORY:[hidden email] with a ccname of  "[hidden email]"

There are process restarts between the tests of course so every test is a clean base. Same test - only difference is in the naming of the ccache. And gss_acquire_cred_from() uses desired_name of "[hidden email]"  ( used as "u:[hidden email]" as input to import_name() utility)

Thanks again Greg. 








    On Thursday 23 May 2019, 23:30:49 GMT+1, Greg Hudson <[hidden email]> wrote:  
 
 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 [hidden email] 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 [hidden email] ->
> krbtgt/[hidden email] in MEMORY:[hidden email]
>
> 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?

 
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

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

Greg Hudson
On 5/24/19 9:38 AM, moore moore wrote:
> But the subsequent call to gss_acquire_cred_from() ( same code path as
> above ) fails with:
>
> [10940] 1558700394.80066: Retrieving [hidden email] 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

As I said before, this trace message is not why the operation is
failing.  If acquire_cred cannot find creds in the ccache, it will check
if they could be acquired via a client keytab.  You need to look for the
ccache operations that failed earlier in the trace output.

> So why is the there a difference on gss_acquire_cred_from() between
> MEMORY:MY_CRED_STORE with a ccname of "[hidden email]"
> and
> MEMORY:[hidden email] with a ccname of  "[hidden email]"

I can't answer this without seeing the actual relevant trace messages.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: 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:[hidden email]
>  store:0x6ddf68, elem:0x6ddf78
>
> [28197] 1558713187.312227: Retrieving [hidden email] 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.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

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

moore moore
 Thank you GregI finally have it working now. By preserving the cred handles I can reuse.
This is working in multi threaded process. However with about 20 concurrent threads, there appears major lock up in the threads (all in the krb5 lib) around malloc and memory management.
krb5_is_thread_safe() returns true (1).

Is there anything to be mindful of in multi threaded context?
samples:
Thread 120 (Thread 0x2af66bc60700 (LWP 59755)):#0  __lll_lock_wait_private () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:95#1  0x00002af669d39bca in _L_lock_10381 () at malloc.c:5201#2  0x00002af669d37705 in __GI___libc_malloc (bytes=28) at malloc.c:2884#3  0x00002af668bb0001 in ?? () from /lib/x86_64-linux-gnu/libkrb5.so.3#4  0x00002af668bb057f in ?? () from /lib/x86_64-linux-gnu/libkrb5.so.3#5  0x00002af668bacdc2 in krb5_get_server_rcache () from /lib/x86_64-linux-gnu/libkrb5.so.3#6  0x00002af668ba5639 in ?? () from /lib/x86_64-linux-gnu/libkrb5.so.3#7  0x00002af668ba5cfa in krb5_rd_req_decoded () from /lib/x86_64-linux-gnu/libkrb5.so.3

Thread 121 (Thread 0x2af66b969700 (LWP 59754)):#0  __lll_lock_wait_private () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:95#1  0x00002af669d39bca in _L_lock_10381 () at malloc.c:5201#2  0x00002af669d37705 in __GI___libc_malloc (bytes=16) at malloc.c:2884#3  0x00002af668b8aeb2 in krb5_copy_data () from /lib/x86_64-linux-gnu/libkrb5.so.3#4  0x00002af668b8acc1 in ?? () from /lib/x86_64-linux-gnu/libkrb5.so.3#5  0x00002af668b909b1 in krb5_get_credentials () from /lib/x86_64-linux-gnu/libkrb5.so.3#6  0x00002af668e48a61 in get_credentials (server=<optimized out>, out_creds=<synthetic pointer>, endtime=<optimized out>, now=1559651781, cred=0x2af680902950, context=0x2af683264100) at init_sec_context.c:196#7  kg_new_connection (exts=0x2af66b958070, context=0x2af683264100, time_rec=0x2af66b9581a4, ret_flags=0x0, output_token=0x2af66b958200, actual_mech_type=0x0, input_token=0x0, input_chan_bindings=0x0, time_req=4294967295, req_flags=<optimized out>, mech_type=0x2af6690655a0 <krb5_gss_oid_array>, target_name=<optimized out>, context_handle=0x2af6841045b0, cred=0x2af680902950, minor_status=0x2af66b9581a0) at init_sec_context.c:587

Thread 122 (Thread 0x2af66beb3700 (LWP 59753)):#0  __lll_lock_wait_private () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:95#1  0x00002af669d39bca in _L_lock_10381 () at malloc.c:5201#2  0x00002af669d37705 in __GI___libc_malloc (bytes=28) at malloc.c:2884#3  0x00002af668bb0001 in ?? () from /lib/x86_64-linux-gnu/libkrb5.so.3#4  0x00002af668bb057f in ?? () from /lib/x86_64-linux-gnu/libkrb5.so.3#5  0x00002af668bacdc2 in krb5_get_server_rcache () from /lib/x86_64-linux-gnu/libkrb5.so.3#6  0x00002af668ba5639 in ?? () from /lib/x86_64-linux-gnu/libkrb5.so.3#7  0x00002af668ba5cfa in krb5_rd_req_decoded () from /lib/x86_64-linux-gnu/libkrb5.so.3#8  0x00002af668e3e210 in kg_accept_krb5 (minor_status=0x2af66bea20dc, context_handle=0x2af68052d240, verifier_cred_handle=0x2af6813def50, input_token=<optimized out>, input_chan_bindings=0x0, src_name=0x2af66bea1dc8, mech_type=mech_type@entry=0x2af66bea1dd8, output_token=output_token@entry=0x2af66bea1f20, ret_flags=ret_flags@entry=0x2af66bea1db4, time_rec=time_rec@entry=0x0, delegated_cred_handle=delegated_cred_handle@entry=0x2af66bea1dc0, exts=exts@entry=0x2af66bea1d40) at accept_sec_context.c:644#9  0x00002af668e3f5a4 in krb5_gss_accept_sec_context_ext (minor_status=0x2af66bea20dc, context_handle=0x2af68052d240, verifier_cred_handle=<optimized out>, input_token=<optimized out>, input_chan_bindings=<optimized out>, src_name=<optimized out>, mech_type=mech_type@entry=0x2af66bea1dd8, output_token=output_token@entry=0x2af66bea1f20, ret_flags=ret_flags@entry=0x2af66bea1db4, time_rec=time_rec@entry=0x0, delegated_cred_handle=delegated_cred_handle@entry=0x2af66bea1dc0, exts=exts@entry=0x2af66bea1d40) at accept_sec_context.c:1308

Thread 123 (Thread 0x2af66b840700 (LWP 59752)):#0  __lll_lock_wait_private () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:95#1  0x00002af669d39bca in _L_lock_10381 () at malloc.c:5201#2  0x00002af669d37705 in __GI___libc_malloc (bytes=24) at malloc.c:2884#3  0x00002af668bb9f34 in ?? () from /lib/x86_64-linux-gnu/libkrb5.so.3#4  0x00002af668bba10a in k5_os_init_context () from /lib/x86_64-linux-gnu/libkrb5.so.3#5  0x00002af668b9689f in krb5_init_context_profile () from /lib/x86_64-linux-gnu/libkrb5.so.3#6  0x00002af668e51086 in krb5_gss_release_name (minor_status=0x2af66b82f104, input_name=0x2af67f4900b0) at rel_name.c:34#7  0x00002af668e32fb8 in gssint_release_internal_name (minor_status=minor_status@entry=0x2af66b82f104, mech_type=<optimized out>, internal_name=internal_name@entry=0x2af67f4900b0) at g_glue.c:577#8  0x00002af668e3b007 in gss_release_name (minor_status=minor_status@entry=0x2af66b82f104, input_name=input_name@entry=0x2af66b82f108) at g_rel_name.c:78
    On Friday 24 May 2019, 19:07:25 GMT+1, Greg Hudson <[hidden email]> wrote:  
 
 On 5/24/19 12:19 PM, moore moore wrote:
> gss_acquire_cred_from() for gss_name:u:[hidden email]
>  store:0x6ddf68, elem:0x6ddf78
>
> [28197] 1558713187.312227: Retrieving [hidden email] 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.
 
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

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

Greg Hudson
On 6/4/19 5:38 PM, moore moore wrote:> This is working in multi threaded
process. 
> However with about 20 concurrent threads, there appears major lock up in
> the threads (all in the krb5 lib) around malloc and memory management.

The only ways I can think of for code to cause a deadlock inside
malloc() are memory corruption and calling malloc() from within a signal
handler (directly or indirectly).

You might try using valgrind or asan to look for memory corruption bugs.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev