Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> On 04/06/10 22:33, Tom Lane wrote:
>> A counterexample: suppose we had a form of type "text" that carried a
>> collation specifier internally, and the comparison routine threw an
>> error if asked to compare values with incompatible specifiers. An index
>> built on a column of all the same collation would work fine. A query
>> that tried to compare against a constant of a different collation would
>> throw an error.
> I can't take that example seriously. First of all, tacking a collation
> specifier to text values would be an awful hack.
Really? I thought that was under serious discussion. But whether it
applies to text or not is insignificant; I believe there are cases just
like this in existence today for some datatypes (think postgis).
The real point is that the comparison constant is under the control of
the attacker, and it's not part of the index. Therefore "it didn't
throw an error during index construction" proves nothing whatever.
> ... Secondly, it would be a
> bad idea to define the b-tree comparison operators to throw an error;
You're still being far too trusting, by imagining that only *designed*
error conditions matter here. Think about overflows, out-of-memory,
(perhaps intentionally) corrupted data, etc etc.
I think the only real fix would be something like what Marc suggested:
if there's a security view involved in the query, we simply don't give
the client the real error message. Of course, now our "security
feature" is utterly disastrous on usability as well as performance
counts ...
regards, tom lane
