[15628] in Kerberos_V5_Development
Re: prompter type question
daemon@ATHENA.MIT.EDU (Greg Hudson)
Mon Mar 22 18:13:57 2010
From: Greg Hudson <ghudson@mit.edu>
To: Nicolas Williams <Nicolas.Williams@sun.com>
In-Reply-To: <20100322205700.GH19496@Sun.COM>
Date: Mon, 22 Mar 2010 18:13:51 -0400
Message-ID: <1269296031.7493.398.camel@ray>
Mime-Version: 1.0
Cc: MIT Kerberos Dev List <krbdev@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On Mon, 2010-03-22 at 16:57 -0400, Nicolas Williams wrote:
> We need to hear from the maintainers, please.
Sorry, things have been busy, and this isn't an issue I can just dash
off a reply to. Here are my notes after looking through the code and
rereading the thread:
* The prompters in the krb5 tree (prompter_posix, KIM, KfW) either don't
care about the prompt type at all, or only care whether it's a password
prompt. (KIM wants to save the password in some cases, while KfW treats
an empty password as a cancellation request by the user).
* As usual, with no API docs, we're stuck trying to guess at our
compatibility guarantees. Would third-party prompter invocations get
confused by prompter types which didn't exist before? If so, is it
their fault or ours?
* Warning messages are currently displayed by invoking the prompter with
a banner value and no prompts--which means there is no associated prompt
type. So a prompt type for warning messages is probably unnecessary.
* A prompt type for error messages doesn't make sense to me; I would
expect plugins to just return an error code and possibly use
krb5_set_error_message() to better explain it, rather than invoking the
prompter to display an error message.
* Before we get into enumerating all of the possible bits of information
a preauth mechanism might need to retrieve, I'd want to think a bit
about what we are trying to enable prompters to do with that
information, whether it's okay to keep expanding the set as time goes
on, and whether we envision using this interface to retrieve non-textual
input such as biometric data.
* If we decide it's okay to expand the set of prompt types now, we can
presumably do so again later--that is, we don't have to add prompt types
no one has expressed a need for just to avoid adding more later.
Following that argument, a conservative option is to add a prompt type
for requesting only a continue/cancel indication, and no actual data.
That would allow a GUI prompt for "insert token" to avoid having a
pointless (and misleading) text entry field.
To summarize my position:
* I am okay with using KRB5_PROMPT_TYPE_PREAUTH as Sam suggests.
* I can see value in adding KRB5_PROMPT_TYPE_CONTINUE if no one thinks
it is likely to create compatibility issues.
* I am reluctant to add a bunch of new prompt types just because we
happen to be touching the list and want it to be more complete.
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
