Improve RLS planning by marking individual quals with security levels.

In an RLS query, we must ensure that security filter quals are evaluated
before ordinary query quals, in case the latter contain "leaky" functions
that could expose the contents of sensitive rows.  The original
implementation of RLS planning ensured this by pushing the scan of a
secured table into a sub-query that it marked as a security-barrier view.
Unfortunately this results in very inefficient plans in many cases, because
the sub-query cannot be flattened and gets planned independently of the
rest of the query.

To fix, drop the use of sub-queries to enforce RLS qual order, and instead
mark each qual (RestrictInfo) with a security_level field establishing its
priority for evaluation.  Quals must be evaluated in security_level order,
except that "leakproof" quals can be allowed to go ahead of quals of lower
security_level, if it's helpful to do so.  This has to be enforced within
the ordering of any one list of quals to be evaluated at a table scan node,
and we also have to ensure that quals are not chosen for early evaluation
(i.e., use as an index qual or TID scan qual) if they're not allowed to go
ahead of other quals at the scan node.

This is sufficient to fix the problem for RLS quals, since we only support
RLS policies on simple tables and thus RLS quals will always exist at the
table scan level only.  Eventually these qual ordering rules should be
enforced for join quals as well, which would permit improving planning for
explicit security-barrier views; but that's a task for another patch.

Note that FDWs would need to be aware of these rules --- and not, for
example, send an insecure qual for remote execution --- but since we do
not yet allow RLS policies on foreign tables, the case doesn't arise.
This will need to be addressed before we can allow such policies.

Patch by me, reviewed by Stephen Frost and Dean Rasheed.

Discussion: https://postgr.es/m/8185.1477432701@sss.pgh.pa.us

1 files changed, 6 insertions, 8 deletions

diff --git a/src/backend/optimizer/util/clauses.c b/src/backend/optimizer/util/clauses.c
index 59ccdf43d49..9e122e383d8 100644
--- a/src/backend/optimizer/util/clauses.c
+++ b/src/backend/optimizer/util/clauses.c
@@ -1500,10 +1500,8 @@ contain_context_dependent_node_walker(Node *node, int *flags)
  *
  * Returns true if the clause contains any non-leakproof functions that are
  * passed Var nodes of the current query level, and which might therefore leak
- * data.  Qualifiers from outside a security_barrier view that might leak data
- * in this way should not be pushed down into the view in case the contents of
- * tuples intended to be filtered out by the view are revealed by the leaky
- * functions.
+ * data.  Such clauses must be applied after any lower-level security barrier
+ * clauses.
  */
 bool
 contain_leaked_vars(Node *clause)
@@ -1598,10 +1596,10 @@ contain_leaked_vars_walker(Node *node, void *context)
 		case T_CurrentOfExpr:
 
 			/*
-			 * WHERE CURRENT OF doesn't contain function calls.  Moreover, it
-			 * is important that this can be pushed down into a
-			 * security_barrier view, since the planner must always generate a
-			 * TID scan when CURRENT OF is present -- c.f. cost_tidscan.
+			 * WHERE CURRENT OF doesn't contain leaky function calls.
+			 * Moreover, it is essential that this is considered non-leaky,
+			 * since the planner must always generate a TID scan when CURRENT
+			 * OF is present -- c.f. cost_tidscan.
 			 */
 			return false;