From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Noah Misch <noah(at)leadboat(dot)com> |
Cc: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com>, pgsql-bugs <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: [PATCH] Fixed malformed error message on malformed SCRAM message. |
Date: | 2017-06-02 06:20:00 |
Message-ID: | 27186.1496384400@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
Noah Misch <noah(at)leadboat(dot)com> writes:
> auth.c uses COMMERROR for this sort of thing; why does auth-scram.c use ERROR?
"COMMERROR" is more or less "LOG"; we'd have to throw a different error
afterwards if we reported these messages with COMMERROR.
The main case where COMMERROR is appropriate, I think, is where we think
that communication with the client has already failed and it's unlikely
that what we say will reach the client; but we'd like to be sure it
reaches the postmaster log.
There's a somewhat separate question of whether we'd be exposing useful
information to an attacker if we returned such details to the client.
Not entirely sure if any of these messages fall into that category, but
offhand I think that an attacker would already know if he's violating
protocol.
BTW, since you mention COMMERROR uses in auth.c, isn't the usage at
line 687 wrong? It sure looks like the author supposed that that
ereport call wouldn't return, but it will. Adjacent similar calls
clean up and return NULL.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2017-06-02 06:24:02 | Re: [PATCH] Fixed malformed error message on malformed SCRAM message. |
Previous Message | Noah Misch | 2017-06-02 05:58:59 | Re: [PATCH] Fixed malformed error message on malformed SCRAM message. |
From | Date | Subject | |
---|---|---|---|
Next Message | Noah Misch | 2017-06-02 06:22:58 | Re: retry shm attach for windows (WAS: Re: OK, so culicidae is *still* broken) |
Previous Message | Michael Paquier | 2017-06-02 06:11:24 | Re: Race conditions with WAL sender PID lookups |