From: | Amit Langote <amitlangote09(at)gmail(dot)com> |
---|---|
To: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Logging of PAM Authentication Failure |
Date: | 2013-05-14 02:22:01 |
Message-ID: | CA+HiwqHknjBcXm2F7S_4swWCxZYf+10f6a+GwU8ZYNqHRH8wnw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Well, if we are allowed to use a bit ugry way, the attached patch
> seems to cope with this issue. As far as I can see there's no
> problem since pg_fe_sendauth() refueses to send empty password.
>
> Any suggestions?
That seems to do the trick. This probably solves the problem that I
originally posted.
> Sorry, I've read there incorrectly. I had understood the code
> after sendAuthRequest in pam_passwd_conv_proc but it is used
> indeed.
Though, I am still not sure why we drop the existing connection and
start all over again but now with the newly entered password. This
kind of seems to leave the protocol state machine (as in
PQconnectPoll() ) halfway (after pg_fe_sendauth() failed) in the first
connection attempt for the auth requests requiring the password (or
others, too?). Although, sticking to this design may have to do with
the problems of doing otherwise that I am unaware of.
--
Amit Langote
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2013-05-14 02:27:02 | Re: PostgreSQL 9.3 beta breaks some extensions "make install" |
Previous Message | Tom Lane | 2013-05-14 02:00:40 | Re: PostgreSQL 9.3 beta breaks some extensions "make install" |