On Sat, 13 Aug 2016 12:02:30 -0400
Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Victor Wagner <vitus@wagner.pp.ru> writes:
> > I think it is better to avoid such a problem and fix system so
> > server would never send a message in the encoding, different from
> > client one.
>
> Don't hold your breath waiting for that to happen.
>
> Quite aside from the question of whether we want to trust GUC settings
> from the startup packet before we've authenticated the user, there's a
What's wrong with trusting this particular setting? I cannot think of
any meaningful exploit. Really, there are lot of http servers out
there, which typically do accept connections from anywhere (which is
seldom case for postgresql servers) and trust Accept-Charset and
Accept-Language client header without any authentication.
There can be attacks that exploits errors in the message parsing,
but startup message is parsed anyway before authentication.
> small problem that the server *can't* translate *any* encoding until
> it's successfully connected to a database and is able to read the
> pg_conversion catalog.
>
> We might be able to institute some rule like "examine the startup
> packet and see if it specifies a client_encoding different from what
> we inherited from the postmaster. If not, continue with current
> behavior (send messages localized per postmaster's settings). If so,
> fall back to English messages/C locale until startup is complete."
> This would preserve current functionality in cases where it actually,
> er, functions, while giving something at least passable in the cases
> that are broken today.
I think that we can do a bit more than this. We use GNU gettext
library to provide message translation. These library are able to
perform limited set of encoding conversion itself.
So, we can have two-stage fallback here:
1. If encoding is different, but compatible with language, inherited
from postmaster, ask gettext via bind_textdomain_encoding function to
provide messages in this encoding.
2. If it is not possible, fall back to English messages, which are
compatible with any of supported encoding. The same goes for session
which doesn't specify encoding at all (i.e. CancelMessage).
>
> regards, tom lane
>
>
-- Victor Wagner <vitus@wagner.pp.ru>
