Re: Plans for 9.1, Grouping Sets, disabling multiqueries, contrib module for string, plpgpsm, preload dictionaries

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Plans for 9.1, Grouping Sets, disabling multiqueries, contrib module for string, plpgpsm, preload dictionaries
Date: 2010-02-21 14:23:11
Message-ID: 7344.1266762191@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> * Last two months I spent some time with preparing workshops about SQL
> injection. PostgreSQL has only one issue related to this topic. It
> allows multi queries. With this feature any successful injection can
> have much more destructive impact. Now we have a GUC per user. I know,
> we cannot break multiqueries without breaking basic functionality. But
> we can break multiple queries on top level for some selected users -
> (web application roles). Then we are able to configure database for
> "secure web access". >>It isn't protection against SQL injection<<.

This seems like a waste of effort. It is already the case that multi
queries are forbidden when submitting through the extended query
protocol. All that an app has to do is not use simple protocol ---
which, if it's trying to be secure, it's already not using because
it needs out-of-line parameters.

There's no need for yet another GUC.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-02-21 14:26:33 Re: getting to beta
Previous Message Andrew Dunstan 2010-02-21 13:46:10 Re: scheduler in core