(2010/10/05 23:56), Tom Lane wrote: > Robert Haas<robertmh...@gmail.com> writes: >> Checking the functions of the operators is the right thing to do, but >> assuming that internal = safe does not work. For example, pushing >> down arithmetic operators allows you to probe for any given value in a >> hidden row by testing whether 1 / (x - constant) throws a division by >> zero error. > > Well, if the goal is "make it impossible to tell whether such-and-such a > value exists", I think this approach can't meet it at all. There are > too many side channels. You're focusing here on the error-report side > channel, but there's also performance, ie how long did the query take. > (BTW, is the intent to somehow lobotomize EXPLAIN so you can't use that > to see what happened?) > Good point. Major commercial RDBMS with row-level access control (such as Oracle VPD) does not care about any side channels that allows us to infer existence of a certain value.
Their features focus on control regular data channels. It allows malicious users to transfer contents of invisible tuples into others unexpectedly. It corresponds to a user defined function which insert the supplied argument into temporary table in my example. So, if we should catch up same level earlier, I think we need to ignore such kind of side channel attacks. If so, the matter become much simple. We need to consider whether contents of the error messages are delivered via main-channel or side-channel. If we consider it is a side-channel, we can trust all the buili-in functions because nothing tries to write out the supplied argument into somewhere. If we consider it is a regular-channel, we need to distinguish safe and unsafe functions based on a certain criteria, maybe, 'safe' flag in pg_proc. In my opinion, I like to categorize error messages as side-channel, because its through-put is much less than regular-channels, so scale of the threat is relatively small. Thanks, -- KaiGai Kohei <kai...@kaigai.gr.jp> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
