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() 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. Conversely, the conversation routine is just a glorified "printf", then where in the heck is the password read in, and where is pam_set_item() being called to fill in the details before the call to pam_chauthtok() can actually update the password? Thanks, Ed Ed Phillips <ed at udel.edu> University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key
>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
Just to start a new thread in this discussion... As I asked before, when using an interactive session (plain simple 'ssh <host>'), and the prompt for changing the password appears, this stuff comes out of the PAM library, right ? So the problem that the password (login password first) now entered is non-hidden on the screen comes from PAM, not from ssh ? And why does the password-expiration checking work only with the PAM_TTY_KLUDGE ? If I understood the whole thing, this kludge should only be activated in conjunction with non-interactive sessions. But without it ssh (2.9.9p2 on Sol8) just closes the connection without any hint to the expired password... - Alex
See the Linux-PAM, XSSO and Sun PAM docs here: http://www.kernel.org/pub/linux/libs/pam/ and here: http://docs.sun.com/ Nico On Thu, Oct 25, 2001 at 05:51:20PM -0400, Ed Phillips wrote:> 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() > 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. > > Conversely, the conversation routine is just a glorified "printf", then > where in the heck is the password read in, and where is pam_set_item() > being called to fill in the details before the call to pam_chauthtok() can > actually update the password? > > Thanks, > > Ed > > Ed Phillips <ed at udel.edu> University of Delaware (302) 831-6082 > Systems Programmer III, Network and Systems Services > finger -l ed at polycut.nss.udel.edu for PGP public key-- -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.