Date: Tue, 25 Apr 2017 15:24:08 -0700
From: David Fetter <david@fetter.org>
To: Konstantin Knizhnik <k.knizhnik@postgrespro.ru>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Cached plans and statement generalization
Message-ID: <20170425222408.GF32130@fetter.org>
References: <8e76d8fc-8b8c-14bd-d4d1-e9cf193a74f5@postgrespro.ru>
 <20170424184353.u2krt2eiw2l6e2af@alap3.anarazel.de>
 <f0bfcdd6-dba3-e9a8-2108-146e1f880839@postgrespro.ru>
 <20170425165421.GD32130@fetter.org>
 <58FFB309.5040209@postgrespro.ru>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <58FFB309.5040209@postgrespro.ru>
User-Agent: Mutt/1.8.0 (2017-02-23)
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On Tue, Apr 25, 2017 at 11:35:21PM +0300, Konstantin Knizhnik wrote:
> On 04/25/2017 07:54 PM, David Fetter wrote:
> > On Tue, Apr 25, 2017 at 06:11:09PM +0300, Konstantin Knizhnik wrote:
> > > On 24.04.2017 21:43, Andres Freund wrote:
> > > > Hi,
> > > > 
> > > > On 2017-04-24 11:46:02 +0300, Konstantin Knizhnik wrote:
> > > > > So what I am thinking now is implicit query caching. If the same query with
> > > > > different literal values is repeated many times, then we can try to
> > > > > generalize this query and replace it with prepared query with
> > > > > parameters.
> > > > That's not actuall all that easy:
> > > > - You pretty much do parse analysis to be able to do an accurate match.
> > > >     How much overhead is parse analysis vs. planning in your cases?
> > > > - The invalidation infrastructure for this, if not tied to to fully
> > > >     parse-analyzed statements, is going to be hell.
> > > > - Migrating to parameters can actually cause significant slowdowns, not
> > > >     nice if that happens implicitly.
> > > Well, first of all I want to share results I already get: pgbench with
> > > default parameters,  scale 10 and one connection:
> > > 
> > > protocol
> > > 	TPS
> > > simple
> > > 	3492
> > > extended
> > > 	2927
> > > prepared
> > > 	6865
> > > simple + autoprepare
> > > 	6844
> > If this is string mashing on the unparsed query, as it appears to be,
> > it's going to be a perennial source of security issues.
> 
> Sorry, may be I missed something, but I can not understand how
> security can be violated by extracting string literals from query. I
> am just copying bytes from one buffer to another. I do not try to
> somehow interpret this parameters.  What I am doing is very similar
> with standard prepared statements.  And moreover query is parsed!
> Only query which was already parsed and executed (but with different
> values of parameters) can be autoprepared.

I don't have an exploit yet.  What concerns me is attackers' access to
what is in essence the ability to poke at RULEs when they only have
privileges to read.

Best,
David.
-- 
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david(dot)fetter(at)gmail(dot)com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers