(2010/10/06 0:33), KaiGai Kohei wrote:
> (2010/10/05 23:56), Tom Lane wrote:
>> Robert Haas<robertmhaas@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 <kaigai@kaigai.gr.jp>