context, threads, and both

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

context, threads, and both

John Rudd

While I have been a kerberos realm admin for a while, I'm new to doing
kerberos development (and by that I mean "developing something that
uses kerberos libraries" as opposed to "developing parts of kerberos";
I hope that's what this list is intended for).  So, I have a couple
questions:

1) I'm writing a persistent program which will be checking taking
requests to validate whether or not a principle name and passphrase are
valid.  One instance of the program could end up running for months or
longer.  Right now, I have it doing 1 context initialization, but since
so  many other things in kerberos have life-times, I want to be sure
that I wont need to refresh this with a new initialization
periodically.  Do I just need the one initialization at start-up, or do
I need to re-do that periodically?

2) I seem to recall that kerberos libraries are not thread safe.  Is
that accurate?  If I decide to multi-thread this program, do I need to
wrap the kerberos calls with mutex's?

3) What about the context and each thread?  Does each thread need its
own context?  (does the "is or is not thread-safe" aspect depend upon
whether or not each thread has its own context?)

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

Re: context, threads, and both

Kenneth G Raeburn
Hi, John.

> 1) I'm writing a persistent program which will be checking taking
> requests to validate whether or not a principle name and passphrase
> are valid.  One instance of the program could end up running for
> months or longer.  Right now, I have it doing 1 context
> initialization, but since so  many other things in kerberos have
> life-times, I want to be sure that I wont need to refresh this with a
> new initialization periodically.  Do I just need the one
> initialization at start-up, or do I need to re-do that periodically?

If you keep the context around, you should be able to use it
indefinitely.

> 2) I seem to recall that kerberos libraries are not thread safe.  Is
> that accurate?  If I decide to multi-thread this program, do I need to
> wrap the kerberos calls with mutex's?
>
> 3) What about the context and each thread?  Does each thread need its
> own context?  (does the "is or is not thread-safe" aspect depend upon
> whether or not each thread has its own context?)

That's the idea, yes -- calls can be done in different threads as long
as they use different contexts.  For simple data types exported in the
header file, like the principal structure, we don't have any locking,
so they're only safe to use in multiple threads at once if all of the
uses only read the structure contents (and yeah, that's not really well
documented anywhere).

Ken

P.S.  This is all assuming you're using a fairly current release.  The
1.2 series had none of the thread safety support, for example.  Oh, and
I'm talking about the krb5 and gssapi libraries -- gssrpc hasn't been
done, and krb4 isn't going to be.

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

Re: context, threads, and both

John Rudd

On May 31, 2005, at 20:28, Ken Raeburn wrote:

>> 2) I seem to recall that kerberos libraries are not thread safe.  Is
>> that accurate?  If I decide to multi-thread this program, do I need
>> to wrap the kerberos calls with mutex's?
>>
>> 3) What about the context and each thread?  Does each thread need its
>> own context?  (does the "is or is not thread-safe" aspect depend upon
>> whether or not each thread has its own context?)
>
> That's the idea, yes -- calls can be done in different threads as long
> as they use different contexts.  For simple data types exported in the
> header file, like the principal structure, we don't have any locking,
> so they're only safe to use in multiple threads at once if all of the
> uses only read the structure contents (and yeah, that's not really
> well documented anywhere).

So, if each one keeps its own principle, creds, and context data
separate, all should be good?

> P.S.  This is all assuming you're using a fairly current release.  The
> 1.2 series had none of the thread safety support, for example.  Oh,
> and I'm talking about the krb5 and gssapi libraries -- gssrpc hasn't
> been done, and krb4 isn't going to be.

We're still in 1.2.x, so I probably wont bother trying to multi-thread
my program until later this summer (when we upgrade our kerberos
versions).


John

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

Re: context, threads, and both

Kenneth G Raeburn
On Jun 2, 2005, at 16:56, John Rudd wrote:
> So, if each one keeps its own principle, creds, and context data
> separate, all should be good?

Yes.  Actually, the credential cache code does locking internally, so
if the threads are all using the same client principal, you should be
able to share a credentials cache.  (But any race conditions that might
exist between processes accessing the same on-disk ccache will still
exist in multiple threads independently opening and accessing the same
on-disk ccache, and may require different fixes.)

Ken

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

AW: context, threads, and both

Barbat, Calin
In reply to this post by John Rudd
I encountered this issue (race condition caused by processes simultaneously accessing the same rcache in my case), any idea if and when it'll get fixed? I mean in the MIT Kerberos codebase.

Mit freundlichen Grüßen / Best regards

Calin Barbat
OSRAM GmbH / IT SP6
Hellabrunnerstr. 1
81543 München

-----Ursprüngliche Nachricht-----
Von: [hidden email] [mailto:[hidden email]] Im Auftrag von Ken Raeburn
Gesendet: Freitag, 3. Juni 2005 03:56
An: John Rudd
Cc: [hidden email]
Betreff: Re: context, threads, and both

On Jun 2, 2005, at 16:56, John Rudd wrote:
> So, if each one keeps its own principle, creds, and context data
> separate, all should be good?

Yes.  Actually, the credential cache code does locking internally, so if the threads are all using the same client principal, you should be able to share a credentials cache.  (But any race conditions that might exist between processes accessing the same on-disk ccache will still exist in multiple threads independently opening and accessing the same on-disk ccache, and may require different fixes.)

Ken

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev



_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev