2010/10/12 KaiGai Kohei <kaigai@ak.jp.nec.com>:
> I noticed the previous patch has an obvious conflict to the latest
> git mater, and it does not have any documentation updates.
>
> So, I rebased the patch, and added descriptions about secure views.
> Rest of parts are unchanged.
It seems that we have rough agreement that the existing VIEW feature
is adequate for column filtering but not for row filtering. The
attack vector is that the planner might reorder quals such that a
value not intended to be visible to the user is passed to a function
which has a side-effect that can expose the value passed to it: either
overtly (as by a user-defined function that writes it to the table or
prints it using RAISE NOTICE) or in some more subtle way (as in the
case where division by zero exposes throws an exception when passed
zero, but not some other value). With the possible exception of Tom,
everyone seems to agree that it would be a good step forward to
provide a way of plugging these holes, even if it didn't cover subtler
information leaks such as by reading the EXPLAIN output or timing
query execution.
1. Does anyone wish to argue (or continue arguing) that plugging these
more overt information leaks is not worthwhile?
2. Supposing that the answer to question #1 is in the negative, does
anyone wish to argue that this patch as currently written is an
adequate solution to this problem? It seems obvious to me that it
isn't.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
