[11200] in Kerberos-V5-bugs
Re: [krbdev.mit.edu #6430] If we fail to generate preauth, don't loop
daemon@ATHENA.MIT.EDU (Sam Hartman via RT)
Tue Oct 13 12:28:31 2009
X-Barracuda-Envelope-From: nobody@krbdev.mit.edu
Mail-Followup-To: rt@krbdev.mit.edu
mail-copies-to: never
From: "Sam Hartman via RT" <rt-comment@krbdev.MIT.EDU>
In-Reply-To: <rt-6430@krbdev.mit.edu>
Message-ID: <rt-6430-31812.0.043036915030612@krbdev.mit.edu>
To: "'AdminCc of krbdev.mit.edu Ticket #6430'":;"'AdminCc of krbdev.mit.edu Ticket #6430'":;@MIT.EDU
Date: Tue, 13 Oct 2009 16:26:21 +0000 (UTC)
Reply-To: rt-comment@krbdev.MIT.EDU
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krb5-bugs-bounces@mit.edu
Greg, a couple of points. First, you do have code to track whether a
module has been used in the plugin path, but not in the internal
preauth system path. ( I assumed it was in both places). So, for
plugins, keeping track of whether you've already given up on a plugin
is relatively easy.
You do actually support optimistic preauth. There is both a config
parameter and a get_init_creds option to set the list of preauth types
to optimistically try. I think a reasonable medium-term fix for this
issue would be to treat preauth_failed as preauth_required in the
optimistic case but not in other cases. Long term, it would perhaps
be more correct to treat preauth_failed as preauth_required once you
had a mechanism for keeping track of preauth state better. Perhaps
getting rid of separate dispatch for built-in and plugins and simply
synthesizing plugin state for the built-in mechanisms would be a good
(post 1.8) wishlist item.
--Sam
_______________________________________________
krb5-bugs mailing list
krb5-bugs@mit.edu
https://mailman.mit.edu/mailman/listinfo/krb5-bugs
