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