Re: [BUGS] [PATCH] Fixed malformed error message on malformed SCRAM message.
От | Tom Lane |
---|---|
Тема | Re: [BUGS] [PATCH] Fixed malformed error message on malformed SCRAM message. |
Дата | |
Msg-id | 27186.1496384400@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [BUGS] [PATCH] Fixed malformed error message on malformed SCRAM message. (Noah Misch <noah@leadboat.com>) |
Ответы |
Re: [BUGS] [PATCH] Fixed malformed error message on malformed SCRAMmessage.
|
Список | pgsql-bugs |
Noah Misch <noah@leadboat.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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
В списке pgsql-bugs по дате отправления: