PAM conversation stuff

[Darren Moffat]

>Okay, I'm confused again.  They way you guys are talking about the
>conversation routine, it would seem that you think it is a way to fetch
>something from the user - like a new password.  Is this possible?  Does
>calling pam_chauthtok() cause the underlying pam_sm_chauthtok()

When an application calls pam_start (or pam_set_item(pamh, PAM_CONV, &conv),
it passes a pointer to a function to be called by any module that needs
to do IO with the user.


pam_chauthok() lives in libpam it calls pam_sm_chauthtok() (twice) for
each module in the password stack (note password != passwd) for the current
service.  If a particular pam_sm_chauthtok() wishes to do IO with the user
it does pam_get_item(pamh, PAM_CONV, &conv) and gets the function pointer
out of that structure, it may set PAM_USER_PROMPT before calling it.

This puts you back into sshd in this case (auth-pam.c) so if sshd can't
do any IO with the user the converstation function should return a failure
message which will cause that pam_sm_chauthtok to fail and (depending on
the control-flags in pam.conf) the whole pam_chauthtok() call which then
puts us backinto sshd gain with something like PAM_AUTHTOK_ERR at which
point it is upto sshd to decied what to do but as many have pointed out
the expected and probably correct thing to do is close the connection.

Closing the connection is consistant with what happens with telent on
Solaris if you don't provide a new password on expiry.

>eventually print something on stdout and read a new password from stdin
>(the socket to the client) using the conversation routine?  If this is
>what is happening, then logically the bug is in the part of the
>conversation routine that isn't checking to see if stdin/stdout is a TTY
>before trying to prompt the user for info.

Correct.

--
Darren J Moffat