[16027] in Kerberos_V5_Development
Re: Plugin project proposal
daemon@ATHENA.MIT.EDU (Jeffrey Hutzelman)
Sun Aug 1 21:19:05 2010
Date: Sun, 01 Aug 2010 21:19:00 -0400
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: Nicolas Williams <Nicolas.Williams@oracle.com>,
Russ Allbery <rra@stanford.edu>
Message-ID: <80AA330EF67321EB5CDAE62F@atlantis.pc.cs.cmu.edu>
In-Reply-To: <20100715213219.GR22556@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
Cc: krbdev@mit.edu, jhutz@cmu.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
--On Thursday, July 15, 2010 04:32:20 PM -0500 Nicolas Williams
<Nicolas.Williams@oracle.com> wrote:
> On Thu, Jul 15, 2010 at 02:23:49PM -0700, Russ Allbery wrote:
>> Zhanna Tsitkova <tsitkova@mit.edu> writes:
>> > The assumption here was that krb5 contexts are usually created at the
>> > start-up, are long-living and there are very few contexts created.
>>
>> In an ideal situation, this would probably be the case, but there are a
>> lot of real-world situations that do password authentication with some
>> volume. A typical use pattern for such an application is to generate a
>> new krb5_context for every authentication attempt (usually because that's
>> encapsulated in a PAM module or similar plugin). I suspect you will find
>> many situations where it's common to have several krb5_contexts created
>> and freed per second.
>
> Exactly. Now suppose you've a plugin whose initializer likes to do
> things like, say, DNS lookups (for SRV RRs, perhaps, to discover
> services).
>
> Now krb5_init_context() could take a very long time to complete indeed.
Yes; that would suck, a lot.
-- Jeff
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
