Re: Better detail logging for password auth failures

From: Edson - Amplosoft Software <edson(at)openmailbox(dot)org>
To: Noah Misch <noah(at)leadboat(dot)com>,Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andres Freund <andres(at)anarazel(dot)de>,pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Better detail logging for password auth failures
Date: 2015-12-31 16:09:35
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Em 31 de dezembro de 2015 04:56:55 BRST, Noah Misch <noah(at)leadboat(dot)com> escreveu:
>On Wed, Dec 30, 2015 at 10:18:35AM -0500, Tom Lane wrote:
>> Andres Freund <andres(at)anarazel(dot)de> writes:
>> > On 2015-12-29 11:07:26 -0500, Tom Lane wrote:
>> >> In passing, the patch gets rid of a vestigial
>> >> call; it was added by e710b65c and IMO should have been removed
>> >> by 6647248e. There's certainly no very good reason to have one
>> >> at that spot anymore.
>> > Why? Doesn't seem like the worst place for an explicit interrupt
>> > I think we don't really have a problem with too many such checks...
>> > surely could move it, but I don't really see how it's related to
>> > topic at hand nor do I think it's really worth pondering about
>> > extensively.
>> The only reason there was one there at all was that e710b65c added
>> code like this:
>> + /*
>> + * Disable immediate interrupts while doing database access.
>> + * we don't bother to turn this back on if we hit one of the
>> + * conditions, since we can expect we'll just exit right away
>> + */
>> + ImmediateInterruptOK = false;
>> ... some catalog access here ...
>> + /* Re-enable immediate response to SIGTERM/SIGINT/timeout
>interrupts */
>> + ImmediateInterruptOK = true;
>> + /* And don't forget to detect one that already arrived */
>> In 6647248e you got rid of nine of these ten lines, leaving something
>> that's both pointless and undocumented. There are more than enough
>> CHECK_FOR_INTERRUPTS calls already in the auth code; there's not a
>> reason to expend code space on one here. (If MD5 ran long enough to
>> be worth interrupting, there would be an argument for a check inside
>> its hashing loop, but that still wouldn't be this check.)
>I see no general benefit from being parsimonious with
>calls or documenting them. As you explain, it's probably fine to
>remove the
>two calls that commit e710b65 had added. However, the sole connection
>$SUBJECT is one of those two calls sharing a screenful with lines
>changed. The removal, if worthwhile, is worth a freestanding patch.
>Squashing the changes makes both topics harder to review.
>Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
>To make changes to your subscription:

Sent from my Android device with K-9 Mail. Please excuse my brevity.

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message David Steele 2015-12-31 16:30:08 PostgreSQL Audit Extension
Previous Message Alvaro Herrera 2015-12-31 15:14:30 2016-01 Commitfest