[33617] in Kerberos
Re: threading best practices?
daemon@ATHENA.MIT.EDU (Nico Williams)
Fri Jul 22 18:10:12 2011
MIME-Version: 1.0
In-Reply-To: <4E29EFCF.90203@d6.com>
Date: Fri, 22 Jul 2011 17:10:05 -0500
Message-ID: <CAK3OfOixqrY3gRR4wb3dnuO7bDWctD=Gv-R0+Ywpzq-V+W=aqA@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Chris Hecker <checker@d6.com>
Cc: "kerberos@mit.edu" <kerberos@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
On Fri, Jul 22, 2011 at 4:46 PM, Chris Hecker <checker@d6.com> wrote:
>>> Okay, so if I krb5_get_credentials on the KDC thread, I can then
>>> use them in the main thread with a different context...
>> Yes, pretty much.
>
> So, I should create the auth_context in the thread that's doing the
> actual communication with each other machine, right? There seem to be
Yes, but that's not a requirement.
> some calls to DNS in various functions, so I'm going to need to be
> careful to make sure everything's cached in the KDC thread so nothing
> blocks on the other threads...
krb5_mk_req*() should not require any DNS lookups.
krb5_sname_to_principal() can do blocking network I/O for principal
canonicalization (let's not get started on that) and
krb5_get_credentials() can do blocking network I/O (TGS exchange(s) to
get the desired service ticket).
Why are you not using the GSS-API?
> I'm building a test program so I can figure out exactly what needs to be
> where for my use-case.
Great!
> I assume I can have multiple auth_contexts in a single thread, as long
> as I keep straight which one is talking to which other client or server
> and pass them to mk_safe/mk_priv appropriately...
Right.
Nico
--
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
