[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RFE: prompt_types, as with MIT krb5 1.2.x
On Fri, May 11, 2001 at 10:09:49PM +0200, Assar Westerlund wrote:
> Nicolas Williams <Nicolas.Williams@ubsw.com> writes:
> > Indeed. I do not argue otherwise. If you wish to add prompt type info to
> > the struct krb5_prompt that's fine with me and I'll see to it that
> > PAM_KRB5 supports that (yet more autoconf/ifdef magic; sigh).
> How's this instead? I add type information to krb5_prompt and you
> make MIT take the equivalent patches, that way you will not have to do
> any autoconf testing. :-)
I won't expect MIT to do that, but I'll accept the change you suggest
for Heimdal, and if we're stuck doing autoconf/ifdef magic, so be it.
Mind you, the prompts could be associated with the context the way
prompt_types are in MIT, after all, neither Heimdal nor MIT krb5 will
ever get to the point where multiple threads can use the *same* context
at the same time, so there can only be one krb5_get_init_creds_password()
call active on a given context. That said, I do think it's icky to have
one thing be passed to the prompter directly, and the other indirectly.
Also, on a tangentially related note, typed krb5_prompts are the perfect
pre-cursor to having a driver SPI for hardware pre-auth on the client
side... What I have in mind is a list of pre-auth driver prompt
function/data pointer pairs loaded dynamically and krb5_gic*() would try
those first for obtaining answers to pre-auth related prompts.