threading best practices?
Greg Hudson
ghudson at MIT.EDU
Thu Jul 21 23:45:32 EDT 2011
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