threading best practices?

Chris Hecker checker at d6.com
Fri Jul 22 01:03:48 EDT 2011


> I don't think any u2u stuff is stored in a krb5_context. Can you be
> more specific about what you're seeing here?

I'm not seeing anything yet, since I'm still trying to figure out how 
I'm going to do this by playing around with the sample apps.  I think 
I'm getting confused between krb5_context and krb5_auth_context, I'm not 
totally clear on how they relate or depend on one another...

> Objects like credentials and ccaches can be obtained with one library
> context and used in another.

Okay, so if I krb5_get_credentials on the KDC thread, I can then use 
them in the main thread with a different context...

I think I need to figure out exactly what I need to do, and then I'll 
have more of a clue for asking questions.

Thanks,
Chris


On 2011/07/21 20:45, Greg Hudson wrote:
> On Thu, 2011-07-21 at 23:01 -0400, Chris Hecker wrote:
>> I need to do normal client<->server authn and also client<->client
>> authn, which I'm going to do with the user-to-user stuff, so I'll need
>> to talk to the KDC multiple times per session.  It seems like the u2u
>> stuff is stored in the context, so I'm not sure how to make all this work.
>
> I don't think any u2u stuff is stored in a krb5_context.  Can you be
> more specific about what you're seeing here?
>
> In general, you should be able to have a separate krb5_context in each
> thread, and just configure them all the same way (if you need to
> configure them at all).  Objects like credentials and ccaches can be
> obtained with one library context and used in another.  You need to know
> what is internally locked (or internally immutable) and what is not to
> know when the same object can be used in multiple threads
> simultaneously, which is unfortunately underdocumented.
>
>> I'd also like to guarantee nobody in krb5 will try to use a socket
>> without me specifically asking them to, so is there a list of APIs that
>> talk to the net?  An example is some APIs have a flag that tells them to
>> fail with an error code instead of contact the KDC, which is what I
>> want.  Can anybody think of APIs I need to watch out for here?
>
> I'm not sure there is such a list.  We've added a lot of API
> documentation in the form of Doxygen comments on the trunk for the 1.10
> release, which may help.
>
>
>



More information about the Kerberos mailing list