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 <amitlangot...@gmail.com> Date: Fri, May 17, 2013 at 1:29 AM Subject: Re: [HACKERS] Logging of PAM Authentication Failure To: Tom Lane <t...@sss.pgh.pa.us> Cc: Andres Freund <and...@2ndquadrant.com>, Kyotaro HORIGUCHI <kyota.horigu...@gmail.com>, Kyotaro HORIGUCHI <horiguchi.kyot...@lab.ntt.co.jp>, Robert Haas <robertmh...@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org> On Fri, May 17, 2013 at 1:05 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Amit Langote <amitlangot...@gmail.com> writes: >> On Thu, May 16, 2013 at 8:01 PM, Andres Freund <and...@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
pamauth_duplog_quickfix.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
