mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-09-16 12:20:19 +02:00
76c09dbe8d
pam_message array contains exactly one PAM_PROMPT_ECHO_OFF message. Instead, deal with however many messages there are, and don't throw error for PAM_ERROR_MSG and PAM_TEXT_INFO messages. This logic is borrowed from openssh 5.2p1, which hopefully has seen more real-world PAM usage than we have. Per bug #5121 from Ryan Douglas, which turned out to be caused by the conv_proc being called with zero messages. Apparently that is normal behavior given the combination of Linux pam_krb5 with MS Active Directory as the domain controller. Patch all the way back, since this code has been essentially untouched since 7.4. (Surprising we've not heard complaints before.) |
||
---|---|---|
.. | ||
auth.c | ||
be-fsstubs.c | ||
be-secure.c | ||
crypt.c | ||
hba.c | ||
ip.c | ||
Makefile | ||
md5.c | ||
pg_hba.conf.sample | ||
pg_ident.conf.sample | ||
pqcomm.c | ||
pqformat.c | ||
pqsignal.c | ||
README.SSL |
$PostgreSQL: pgsql/src/backend/libpq/README.SSL,v 1.7 2008/10/24 11:48:29 mha Exp $ SSL === >From the servers perspective: Receives StartupPacket | | (Is SSL_NEGOTIATE_CODE?) ----------- Normal startup | No | | Yes | | (Server compiled with USE_SSL?) ------- Send 'N' | No | | | | Yes Normal startup | | Send 'S' | | Establish SSL | | Normal startup >From the clients perspective (v6.6 client _with_ SSL): Connect | | Send packet with SSL_NEGOTIATE_CODE | | Receive single char ------- 'S' -------- Establish SSL | | | '<else>' | | Normal startup | | Is it 'E' for error ------------------- Retry connection | Yes without SSL | No | Is it 'N' for normal ------------------- Normal startup | Yes | Fail with unknown ---------------------------------------------------------------------------