(2010/06/01 22:16), Robert Haas wrote: > 2010/6/1 Heikki Linnakangas<[email protected]>: >> 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. > It is a good point, I think.
Even if we can guess or estimate something from circumstances, it does not allow unprivileged users to read information directly. In fact, we cannot find such a functionality to prevent side-channel leaks from the certification reports of commercial RDBMS with RLS (e.g; Oracle Label Security). However, the leaky VIEWs has a different characteristic. It unintentionally allows to fetch contents of invisible tuples and move into into other tables. It means here is a data flow channel (not side channel), but it breaks restriction of security views. Thanks, -- KaiGai Kohei <[email protected]> -- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
