Previous discussion in 2010

Prerequisites

Before we can try to tackle row-level security generally, using labels or not, we need to fix the issues with data leaks in views.

This issue is summarized as: an untrusted user can define a function which stores all information it is presented, then query a view using that function in a way which will convince the planner to send every row of the underlying table to the function, thus leaking data in the table which the view was intended to prevent.

In this message, KaiGai pointed out we have two different causes of the problem, but both of them can cause same information leaks.

[1] Unexpected order to evaluate qualifiers on a certain scan plan
- When a scan-plan has multiple qualifiers to filter scanned tuples, the optimizer sort the qualifiers based on their estimated cost to execute. If an exogenetic function has smaller cost than other qualifiers come from view definition, the exogenetic function shall be evaluated earlier than others, then contents of invisible tuples may be provided to malicious user-defined functions.
- It is reordered at order_qual_clauses().
[2] Unexpected qualifier distributions into inside of join loop
- When planner makes a scan plan, it tries to distribute qualifiers of scans into smaller unit as possible as it can. For example, if a function takes arguments only come from a certain table, it will be distributed into scan plan of the table, not outside of the join.
- When a view contains JOIN clause between A and B, user can reference the view with his own WHERE clause. If a clause takes arguments depending on only A, the planner distribute the clause into the scan plan of A. In the reault, tuples to be filtered out may become visible to user defined functions.
- It is distributed at distribute_qual_to_rels().

At the point [2], if we prevent all exogenetic functions to push down into join loops, it will make unignorable performance degradation, although the view might not be intended to security purpose.
It needs a way to provide a hint whether the view is defined for security purpose, or not.
- Tom Lane suggested CREATE SECURITY VIEW AS ... statement.
- It was not concluded which is the default. Security view? Regular view?
- How about a GUC option to specify the default? NACKed.
In addition, Robert Haas suggested to test privileges of users whether they have privileges to reference underlaying tables without vires, or not. If available, it is eventually harmless even if user defined functions are evaluated within join loop.
- Here was one opposition because this check will be applied on planner stage, not execution stage.
KaiGai submitted a proof of concept patch that prevents to push down exogenetic functions into security views.