Re: JDBC Support for standard_conforming_strings - Mailing list pgsql-jdbc

From Kris Jurka
Subject Re: JDBC Support for standard_conforming_strings
Date
Msg-id 45580A6E.2010905@ejurka.com
Whole thread Raw
In response to Re: JDBC Support for standard_conforming_strings  (Michael Paesold <mpaesold@gmx.at>)
Responses Re: JDBC Support for standard_conforming_strings
List pgsql-jdbc
Michael Paesold wrote:
>
> I am sending a work-in-progress patch now, as I have some more questions
> on how to proceed.
>
> Progress so far:

Looks good so far.  So two typos in comments.  Incremental diff attached.

> Question 1:
> -----------
> The V2 code as well as the query-parsing code in
> AbstractJdbc2DatabaseMetaData is either mostly static or has otherwise
> no reference to the connection object. There are two ways to tackle
> this: either pass around standardConformingStrings (the variable name
> could be stdStrings for brevity), or give the code access to the current
> connection.
>

Doesn't really matter how you pass this around.  The patch's usage of an
additional boolean parameter looks fine to me.

> Question 2:
> -----------
> The problem with the V2 protocol code is, that tracking the state of
> standard_conforming_strings is not really possible, AFAICS. Currently I
> just read standard_conforming_strings at startup, and that's it. So as
> soon as someone changes the variable, quoting will be incorrect, which
> is a security issue. Therefore my new suggestion is to used the E''
> string syntax in the V2 protocol path if the server version is >= 8.2.
> The version of the server cannot change during the connection, so we are
> save here.

I'm not super worried about this.  If an administrator changes the value
in postgresql.conf and HUPs the postmaster they really can't expect
every client to pick this up immediately.  Even when we are monitoring
the state (V3) we won't know it has changed until after we execute the
next query (with the wrong escaping setting).  If an interface allows
the user to enter arbitrary SQL such that they can change this setting
then it's not really a security issue because they don't need to break
escaping to sneak a query in because they can already execute any query
they want.

> For question 1, I would then suggest to add an argument to the V2Query
> constructor that tells whether E'' should be used instead of '', or not.

This is a good idea.

> For parsing inside the JDBC driver, we would still rely on the initially
> reported value of standard_conforming_strings. We could also add an URL
> parameter to specify what should be set initially.
>

I'd like to see a generic way of setting any GUC parameter at startup,
instead of just this one.  The existing methods of setting this per user
or per database should be OK.
diff -rc origstandard/org/postgresql/core/Parser.java standard/org/postgresql/core/Parser.java
*** origstandard/org/postgresql/core/Parser.java    Sun Nov 12 22:18:04 2006
--- standard/org/postgresql/core/Parser.java    Sun Nov 12 15:52:19 2006
***************
*** 28,34 ****
                                          boolean standardConformingStrings) {
          if (standardConformingStrings)
          {
!             // don NOT treat backslashes as escape characters
              while (++offset < query.length)
              {
                  switch (query[offset])
--- 28,34 ----
                                          boolean standardConformingStrings) {
          if (standardConformingStrings)
          {
!             // do NOT treat backslashes as escape characters
              while (++offset < query.length)
              {
                  switch (query[offset])
diff -rc origstandard/org/postgresql/jdbc2/AbstractJdbc2Connection.java
standard/org/postgresql/jdbc2/AbstractJdbc2Connection.java
*** origstandard/org/postgresql/jdbc2/AbstractJdbc2Connection.java    Sun Nov 12 22:18:04 2006
--- standard/org/postgresql/jdbc2/AbstractJdbc2Connection.java    Sun Nov 12 16:07:29 2006
***************
*** 969,975 ****
          {
              // With standard_conforming_string off, escape backslashes and
              // single-quotes, but still escape single-quotes by doubling, to
!             // avoid a security hazord if the reported value of
              // standard_conforming_strings is incorrect.
              for (int i = 0; i < str.length(); ++i)
              {
--- 969,975 ----
          {
              // With standard_conforming_string off, escape backslashes and
              // single-quotes, but still escape single-quotes by doubling, to
!             // avoid a security hazard if the reported value of
              // standard_conforming_strings is incorrect.
              for (int i = 0; i < str.length(); ++i)
              {

pgsql-jdbc by date:

Previous
From: Oliver Jowett
Date:
Subject: Re: [HACKERS] server process (PID 1188) exited with exit code
Next
From: "Michael Schmidt"
Date:
Subject: Help with transactions and FK's