Re: PG 9.0 and standard_conforming_strings

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: PG 9.0 and standard_conforming_strings
Дата
Msg-id 603c8f071002031134k5cf1c191lf3098fe56f5cf5df@mail.gmail.com
обсуждение исходный текст
Ответ на Re: PG 9.0 and standard_conforming_strings  (Mark Mielke <mark@mark.mielke.cc>)
Список pgsql-hackers
On Wed, Feb 3, 2010 at 2:25 PM, Mark Mielke <mark@mark.mielke.cc> wrote:
> On 02/03/2010 01:20 PM, Robert Haas wrote:
>> I am not sure I really understand why anyone is a rush to make this
>> change.  What harm is being done by the status quo?  What benefit do
>> we get out of changing the default?  The major argument that has been
>> offered so far is that "if we don't change it now, we never will", but
>> I don't believe that the tenor of this discussion supports the
>> contention that Tom or anyone else never wants to make this change.
>
> For myself, it isn't so much a rush as a sense that the code out there that
> will break, will never change unless forced, and any time seems better than
> never.
>
> Correct me if I am wrong - but I think this issue represents an exploitable
> SQL injection security hole. I switched because I convinced myself that the
> ambiguity of \' represented actual danger. I'm concerned that if the web
> front end doing parameter checking and passing in code using either ''
> quoting or \' quoting can be exploited if the server happens to be
> configured the opposite way. To me, this ambiguity can only be addressed by
> everybody agreeing on the right way to do it, and '' quoting seems like the
> right way to do it to me.

OK, you're wrong.  :-)

Yeah, there's a problem if the client and server are configured in
opposite ways, but flipping the default setting of
standard_conforming_strings is not going to make that problem go away.If anything it's going to make it worse.

...Robert


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: PG 9.0 and standard_conforming_strings
Следующее
От: Tim Bunce
Дата:
Сообщение: Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH]