(2010/10/06 0:33), KaiGai Kohei wrote: > (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 Sorry, prevents ^^^^^^
> 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
