openssh unix dev - Dec 2004 - LinuxPAM and sshd: changing conversation function doesn't work but claims to.

Darren Tucker wrote:
>     OK, here's a smallish testcase that demonstrates the problem
Hrm, attachment seems to have been stripped.  It can also be found at:
http://www.zip.com.au/~dtucker/openssh/wrong-conv-function.c

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
     Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

Hi.
	I'm one of the OpenSSH developers, and I've done some of the work on 
sshd's PAM interface recently.

	I've discovered some behaviour peculiar to LinuxPAM that I can't 
explain: changing the conversation function does not appear to work, 
even though the pam_set_item() call claims to succeed.  The previous 
conversation function is still called.

	Background: the PAM API is a poor fit for the SSH protocol, so the 
conversation function needs to do vastly different things at different 
points in the protocol.  Instead of one enormous multi-mode  function, 
sshd has what is probably a record number of different conversation 
functions (5, in the current development versions).

	One of these is a fairly generic "tty_conv" that interacts with the 
user directly on stdin/stdout and /dev/tty.  Since the user doesn't get 
a pty until quite late in the login process, this function is only used 
for pam_chauthtok() in some cases, and always after sshd has forked to 
set up for the user's shell.

	The code for the chauthtok looks like this (from OpenSSH 3.8.1p1's 
do_pam_chauthtok() in auth-pam.c):


   static struct pam_conv tty_conv = { pam_tty_conv, NULL };
[...]
   sshpam_err = pam_set_item(sshpam_handle, PAM_CONV,
           (const void *)&tty_conv);
   if (sshpam_err != PAM_SUCCESS)
           fatal("PAM: failed to set PAM_CONV: %s",
                 pam_strerror(sshpam_handle, sshpam_err));
   debug("PAM: changing password");
   sshpam_err = pam_chauthtok(sshpam_handle, PAM_CHANGE_EXPIRED_AUTHTOK);


	The conversation functions also have a debug() at the start announcing 
that they've been called and the number of messages passed.

	If I run the server[1] in debug mode with PAM enabled and privilege 
separation off, and connect with SSHv1 with an account that has an 
expired password, the code above will be called, and the debug messages 
will be sent to the client (since stdin/stdout is connected to the pty). 
  Here's the output from the client:

Password:
Response:
debug1: PAM: changing password
debug3: PAM: sshpam_null_conv entering, 2 messages
PAM: pam_chauthtok(): Authentication token manipulation error
debug1: do_cleanup
Connection to localhost closed.

	Despite pam_set_item claiming to succeed (it must have returned 
PAM_SUCCESS otherwise fatal() would have been called), tty_conv is *not* 
called by PAM, the previous conversation function is (which replies 
immediately with PAM_CONV_ERR and thus the pam_chauthtok fails).

	This is a Redhat 9 box with pam-0.75-48.  Similar behaviour has also 
been observed on Debian.  The same sshd code works OK on several other 
PAM platforms.

	I have not been able to replicate this behaviour in a minimal test 
case, but I'm hoping someone will be able to explain it.

	Thanks,
		-Daz.

[1] To reproduce with OpenSSH 3.8.1p1 built with PAM enabled:
# ./sshd -ddd -p 2022 -oUsePAM=yes -oUsePrivilegeSeparation=no
# ssh -1 -p 2022 testuser at localhost

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
     Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.


_______________________________________________
Pam-list mailing list
Pam-list at redhat.com
https://www.redhat.com/mailman/listinfo/pam-list

Darren Tucker wrote:
[about PAM calling the wrong conversation function]
>     I have not been able to replicate this behaviour in a minimal test 
> case, but I'm hoping someone will be able to explain it.
	OK, here's a smallish testcase that demonstrates the problem, run on 
Redhat 9 and Solaris 8.  Note that on Redhat, the call to chauthtok 
(incorrectly) generates a second call to my_conv1, whereas on Solaris 
myconv2 is (correctly) called in the second case.

	Thanks,
		-Daz.

$ uname -svr; rpm -q pam
Linux 2.4.20-31.9 #1 Tue Apr 13 17:41:45 EDT 2004
pam-0.75-48
$ gcc wrong-conv-function.c -lpam
$ sudo ./a.out
[673]: pam_start result 0 (Success)
[673]: my_conv1 called
[673]: pam_acct_mgmt result 12 (Authentication token is no longer valid; 
new one required.)
[674]: pam_set_item result 0 (Success)
[674]: my_conv1 called
[674]: pam_chauthtok result 20 (Authentication token manipulation error)

For comparison, here is the same code run on Solaris 8:

$ uname -svr
SunOS 5.8 Generic_117350-02
$ sudo ./a.out
[20837]: pam_start result 0 (Success)
[20837]: pam_acct_mgmt result 9 (Authentication failed)
[20838]: pam_set_item result 0 (Success)
[20838]: my_conv2 called
[20838]: pam_chauthtok result 6 (Conversation failure)

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
     Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
-------------- next part --------------
_______________________________________________
Pam-list mailing list
Pam-list at redhat.com
https://www.redhat.com/mailman/listinfo/pam-list