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
