keyboard-interactive
Nicolas Williams
Nicolas.Williams at ubsw.com
Fri Jan 11 00:23:41 EST 2002
On Wed, Jan 09, 2002 at 09:48:07PM -0600, Mark D. Roth wrote:
> On Wed Jan 09 23:21 2002 +0100, Markus Friedl wrote:
> OK, so how about this:
>
> * Call the main loop from the PAM conversation function with some
> state telling it where it was called from.
Bingo. Make the mainloop reentrant.
> * When the main loop gets the next message from the client, it can
> return control to the PAM conversation function.
OR perhaps the mainloop can return to the conversation function only if
it's an INFO_RESPONSE message. Else, if handling continues as you
suggest then kbd-interactive messages can't be interleaved with any
others; whether or not sshd should work that way depends on the
protocol drafts.
> * If the client sent an INFO_RESPONSE message, the PAM conversation
> function returns the client's response, and the PAM transaction
> continues normally.
>
> * If the client sent some other type of message, the conversation
> function can return PAM_CONV_ERR to abort the PAM transaction. It
> should also set some state to indicate that the PAM transaction was
> aborted.
>
> * When pam_authenticate() returns, if the transaction was aborted,
> return control to the main loop to handle the request that the
> client sent.
>
> There are some obvious semantics to be worked out in terms of how the
> state is maintained, but the PAM code itself would be fairly
> straightforward. Or is there something I'm missing here?
See above.
> --
> Mark D. Roth <roth at feep.net>
> http://www.feep.net/~roth/
Cheers,
Nico
--
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-
Visit our website at http://www.ubswarburg.com
This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses. The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission. If
verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.
More information about the openssh-unix-dev
mailing list