On Thu, 04 Aug 2016 14:25:52 -0400 Tom Lane <t...@sss.pgh.pa.us> wrote:
> Victor Wagner <vi...@wagner.pp.ru> writes: > > Really, if this response is sent after backend has been forked, > > problem probably can be easily fixed better way - StartupMessage > > contain information about desired client encoding, so this > > information just should be processed earlier than any other > > information from this message, which can cause errors (such as > > database name). > > I think that's wishful thinking. There will *always* be errors that > come out before we can examine the contents of the startup message. > Moreover, until we've done authentication, we should be very wary of > applying client-specified settings at all: they might be malicious. I think that this case can be an exception from the rule "don't apply settings from the untrusted source". Let's consider possible threat model: 1. We anyway parse StartupMessage before authentication. There is nothing we can do with it, so parser should be robust enough, to handle untrusted input. As I can see from the quick glance, it is. 2. When encoding name is parsed, it is used to search in the array of supported encoding. No possible attack here - either it is valid or not. 3. As far as I know, we don't allow client to change language, only encoding, so it is not even possible that attacker could make messages in the log unreadable for the system administartor. So, if we would fix the problem, reported by Peter Eisentraut at the begining of this thread, and fall back to untranslated messages whenever client-requested encoding is unable to represent messages in the server default language, this solution, would be not worse than your solution. There would be fallback to C locale in any case of doubt, but in the case when NLS messages can be made readable, they would be readable. Really, there is at least one case, when fallback to C locale should be done unconditionally - a CancelRequest. In this case client cannot send an encoding, so C locale should be used. As far as I understand it is not the case with SSLRequest. Although it doesn't contain encoding information as well as CancelRequest, errors in subsequent SSL negotiations would be reported by client-side SSL libraries, not by server. -- > > regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
