Re: Logging of PAM Authentication Failure

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

In response to

Responses

Browse pgsql-hackers by date

  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"