2010/10/12 KaiGai Kohei <kai...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
