Re: PRIVATE columns
Joshua D. Drake <jd@commandprompt.com>
From: "Joshua D. Drake" <jd@commandprompt.com>
To: Simon Riggs <simon@2ndQuadrant.com>
Cc: Jan Wieck <JanWieck@yahoo.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>, Kohei KaiGai <kaigai@kaigai.gr.jp>
Date: 2012-12-12T20:41:50Z
Lists: pgsql-hackers
On 12/12/2012 12:12 PM, Simon Riggs wrote: >> Would protecting it the same way, we protect the passwords in pg_authid, be >> sufficient? > > The user backend does need to be able to access the stats data during > optimization. It's hard to have data accessible and yet impose limits > on the uses to which that can be put. If we have row security on the > table but no equivalent capability on the stats, then we'll have > leakage. e.g. set statistics 10000, ANALYZE, then leak 10000 credit > card numbers. > > Selectivity functions are not marked leakproof, nor do people think > they can easily be made so. Which means the data might be leaked by > various means through error messages, plan selection, skullduggery > etc.. > > If it ain't in the bucket, the bucket can't leak it. > I accidentally responded to Simon off-list to this. I understand the need and think it would be a good thing to have. However, the real opportunity here is to make statistics non-user visible. I can't think of any reason that they need to be visible to the standard user? Even if when we set the statistics private, it makes just that column non-visible. Sincerely, Joshua D. Drake -- Command Prompt, Inc. - http://www.commandprompt.com/ PostgreSQL Support, Training, Professional Services and Development High Availability, Oracle Conversion, Postgres-XC @cmdpromptinc - 509-416-6579