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 <[email protected]> Date: Fri, May 17, 2013 at 1:29 AM Subject: Re: [HACKERS] Logging of PAM Authentication Failure To: Tom Lane <[email protected]> Cc: Andres Freund <[email protected]>, Kyotaro HORIGUCHI <[email protected]>, Kyotaro HORIGUCHI <[email protected]>, Robert Haas <[email protected]>, PostgreSQL-development <[email protected]> On Fri, May 17, 2013 at 1:05 AM, Tom Lane <[email protected]> wrote: > Amit Langote <[email protected]> writes: >> On Thu, May 16, 2013 at 8:01 PM, Andres Freund <[email protected]> >> 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 ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
