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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
