I added some logging statements in the pam_passwd_conv_proc function and it gets as far as checking if the password is null then returning PAM_CONV_ERR.
if (strlen(appdata_ptr) == 0) { char *passwd; sendAuthRequest(pam_port_cludge, AUTH_REQ_PASSWORD); passwd = recv_password_packet(pam_port_cludge); if (passwd == NULL) ereport(LOG,(errmsg("RD - passwd is NULL... returning PAM_CONV_ERR"))); return PAM_CONV_ERR; /* client didn't want to send password */ if (strlen(passwd) == 0) { ereport(LOG, (errmsg("empty password returned by client"))); return PAM_CONV_ERR; } appdata_ptr = passwd; } ----- pg log ----- <[unkno...@[unknown] 2009-10-16 12:16:07.033 EDT>LOG: connection received: host=10.0.20.38 port=35945 <rdoug...@tacacs 10.0.20.38(35945) 2009-10-16 12:16:07.065 EDT>LOG: could not receive data from client: Connection reset by peer <rdoug...@tacacs 10.0.20.38(35945) 2009-10-16 12:16:07.065 EDT>LOG: RD - passwd is NULL... returning PAM_CONV_ERR <@ 2009-10-16 12:16:07.071 EDT>LOG: server process (PID 2176) was terminated by signal 11: Segmentation fault <@ 2009-10-16 12:16:07.071 EDT>LOG: terminating any other active server processes <@ 2009-10-16 12:16:07.074 EDT>LOG: all server processes terminated; reinitializing <@ 2009-10-16 12:16:07.194 EDT>LOG: database system was interrupted; last known up at 2009-10-16 12:15:58 EDT <@ 2009-10-16 12:16:07.195 EDT>LOG: database system was not properly shut down; automatic recovery in progress <@ 2009-10-16 12:16:07.196 EDT>LOG: record with zero length at 3/B7D75778 <@ 2009-10-16 12:16:07.196 EDT>LOG: redo is not required <@ 2009-10-16 12:16:07.223 EDT>LOG: database system is ready to accept connections <@ 2009-10-16 12:16:07.223 EDT>LOG: autovacuum launcher started -Ryan -----Original Message----- From: Tom Lane [mailto:t...@sss.pgh.pa.us] Sent: Friday, October 16, 2009 11:11 AM To: Douglas, Ryan Cc: pgsql-bugs@postgreSQL.org Subject: Re: [BUGS] BUG #5121: Segmentation Fault when using pam w/ krb5 Well, we certainly are not going to break pq_recvbuf in such a fundamental way as that ;-). I think that the more likely place to work around this is going to be in pam_passwd_conv_proc() in src/backend/libpq/auth.c. In particular, I see that when it gets a NULL from recv_password_packet (which is what's going to happen when pq_recvbuf returns EOF), it returns PAM_CONV_ERR without bothering to set *resp. I wonder whether we need to be initializing *resp to NULL, or even making it really valid? regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs