Re: [RFC] A tackle to the leaky VIEWs for RLS

2010/6/1 Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)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