Fwd: Logging of PAM Authentication Failure

Поиск
Список
Период
Сортировка
От Amit Langote
Тема Fwd: Logging of PAM Authentication Failure
Дата
Msg-id CA+HiwqFg1MCx6-+fHyu-XZR=3JoBKsPyP4Xsd0T1RMnR1=WsZA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Logging of PAM Authentication Failure  (Amit Langote <amitlangote09@gmail.com>)
Список pgsql-hackers
Hello,

The attached patch by Kyotaro Horiguchi-san fixes a PAM authentication
error logging issue which is that when using PAM authentication,
connection attempts by clients (like psql) result in an unnecessary
logging of failed authentication.

---------- Forwarded message ----------
From: Amit Langote <amitlangote09@gmail.com>
Date: Fri, May 17, 2013 at 1:29 AM
Subject: Re: [HACKERS] Logging of PAM Authentication Failure
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@2ndquadrant.com>, Kyotaro HORIGUCHI
<kyota.horiguchi@gmail.com>, Kyotaro HORIGUCHI
<horiguchi.kyotaro@lab.ntt.co.jp>, Robert Haas
<robertmhaas@gmail.com>, PostgreSQL-development
<pgsql-hackers@postgresql.org>


On Fri, May 17, 2013 at 1:05 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Amit Langote <amitlangote09@gmail.com> writes:
>> On Thu, May 16, 2013 at 8:01 PM, Andres Freund <andres@2ndquadrant.com> wrote:
>>> I unfortunately have to say I don't really see the point of this. The
>>> cost of the additional connection attempt is rather low and we have to
>>> deal with the superflous attempts anyway since there will be old libpqs
>>> around for years. Why is this worth the effort?
>
>> While full connection sequence (with proper authentication exchanges)
>> appears  to go smoothly for other cases (authentication methods), it
>> doesn't quite in this case probably because accounting for such a case
>> was not considered to be as important. But while investigating about
>> the PAM issue (original subject of this thread), it turned out that
>> the occurrence of that minor issue was due to this behavior in libpq.
>
> I have to agree with Andres that it's not clear this is a reasonable
> fix.  To get rid of extra reconnections this way will require not merely
> upgrading libpq, but upgrading every single application that uses libpq
> and is capable of prompting its user for a password.  The odds are
> pretty good that that won't ever happen.

Can this stay in the future releases for new users of libpq to
consider using it (saving them a reconnection, however small a benefit
that is) or at least psql which is being changed to use it anyway? I
only think it makes libpq take into account a connection state that
could be used.

> The real complaint here is that the server-side PAM auth code path is
> losing the information that the client chose to disconnect rather than
> offer a password, and thus logging a message that we could do without.
> What's wrong with just fixing that?

Back in this thread, Horiguchi-san has posted a fix. It seems to fix
the original issue. Attaching his patch here again.

--
Amit Langote


--
Amit Langote

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Atri Sharma
Дата:
Сообщение: Re: request a new feature in fuzzystrmatch
Следующее
От: "Dickson S. Guedes"
Дата:
Сообщение: Re: proposal 9.4. Explain on signal