(2010/06/01 22:16), Robert Haas wrote: > 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. > 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 <kai...@ak.jp.nec.com> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
