2010/6/1 Heikki Linnakangas <heikki.linnakan...@enterprisedb.com>: > The general problem is that it seems like a nightmare to maintain this > throughout the planner. Who knows what optimizations this affects, and > do we need to hide things like row-counts in EXPLAIN output? If we try > to be very strict, we can expect a stream of CVEs and security releases > in the future while we find holes and plug them. On the other hand, > using views to restrict access to underlying tables is a very useful > feature, so I'd hate to just give up. We need to decide what level of > isolation we try to accomplish.
I'm entirely uninspired by the idea of trying to prevent all possible leakage of information via side-channels. Even if we tried to obfuscate the explain output, the user can still potentially get some information by timing how long queries take to execute. I think if we have a hook function that can prevent certain users from running EXPLAIN altogether (and I believe this may already be the case) that's about the appropriate level of worrying about that case. I think the only thing that we can realistically prevent is allowing users to make off with the actual tuples. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
