Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, May 8, 2013 at 10:40 PM, Amit Langote <amitlangote09@gmail.com> wrote:
>> I tried to observe the behavior with md5 method (without -W) and
>> observed that no authentication failure is logged, since server
>> probably behaves differently in response to the psql's first
>> connection request in that case. But, pam method leads to it being
>> logged.
auth_failed() in src/backend/libpq/auth.c intentionally logs nothing for
STATUS_EOF status (ie, client closed the connection without responding).
But it looks like the PAM code path doesn't have a way to return that
status code, even when pam_passwd_conv_proc() knows that that's what
happened, and intentionally printed no log message itself (around line
1870 in HEAD). If there's another response code we could return through
the PAM layer, this could be fixed, and I think it should be.
>> Is this a problem?
> Not really. We could potentially fix it by extending the wire
> protocol to allow the server to respond to the client's startup packet
> with a further challenge, and extend libpq to report that challenge
> back to the user and allow sending a response. But that would break
> on-the-wire compatibility, which we haven't done in a good 10 years,
> and certainly wouldn't be worthwhile just for this.
It's not the wire protocol that's the problem; it's that libpq's client
API doesn't provide a way to ask the calling application for a password
in the midst of a connection attempt.
regards, tom lane