Re: BUG #5121: Segmentation Fault when using pam w/ krb5

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 -----

<[unknown](at)[unknown] 2009-10-16 12:16:07.033 EDT>LOG: connection
received: host=10.0.20.38 port=35945
<rdouglas(at)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
<rdouglas(at)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:tgl(at)sss(dot)pgh(dot)pa(dot)us]
Sent: Friday, October 16, 2009 11:11 AM
To: Douglas, Ryan
Cc: pgsql-bugs(at)postgreSQL(dot)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