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