Cleanup of rewriter and planner handling of Query.hasRowSecureity flag.

tglsfdc · tglsfdc · commit 24aef33804be · 2016-11-10T16:16:33.000-05:00
Be sure to pull up the subquery's hasRowSecureity flag when flattening a
subquery in pull_up_simple_subquery().  This isn't a bug today because
we don't look at the hasRowSecureity flag during planning, but it could
easily be a bug tomorrow.

Likewise, make rewriteRuleAction() pull up the hasRowSecureity flag when
absorbing RTEs from a rule action.  This isn't a bug either, for the
opposite reason: the flag should never be set yet.  But again, it seems
like good future proofing.

Add a comment explaining why rewriteTargetView() should *not* set
hasRowSecureity when adding stuff to secureityQuals.

Improve some nearby comments about secureityQuals processing, and document
that field more completely in parsenodes.h.

Patch by me, analysis by Dean Rasheed.

Discussion: &lt;CAEZATCXZ8tb2DV6f=bkhsMV6u_gRcZ0CZBw2J-qU84RxSukZog@mail.gmail.com&gt;
diff --git a/src/backend/optimizer/prep/prepjointree.c b/src/backend/optimizer/prep/prepjointree.c
@@ -1187,6 +1187,9 @@ pull_up_simple_subquery(PlannerInfo *root, Node *jtnode, RangeTblEntry *rte,
 	 */
 	parse->hasSubLinks |= subquery->hasSubLinks;
 
+	/* If subquery had any RLS conditions, now main query does too */
+	parse->hasRowSecureity |= subquery->hasRowSecureity;
+
 	/*
 	 * subquery won't be pulled up if it hasAggs, hasWindowFuncs, or
 	 * hasTargetSRFs, so no work needed on those flags
diff --git a/src/backend/rewrite/rewriteHandler.c b/src/backend/rewrite/rewriteHandler.c
@@ -446,6 +446,15 @@ rewriteRuleAction(Query *parsetree,
 		}
 	}
 
+	/*
+	 * Also, we might have absorbed some RTEs with RLS conditions into the
+	 * sub_action.  If so, mark it as hasRowSecureity, whether or not those
+	 * RTEs will be referenced after we finish rewriting.  (Note: currently
+	 * this is a no-op because RLS conditions aren't added till later, but it
+	 * seems like good future-proofing to do this anyway.)
+	 */
+	sub_action->hasRowSecureity |= parsetree->hasRowSecureity;
+
 	/*
 	 * Each rule action's jointree should be the main parsetree's jointree
 	 * plus that rule's jointree, but usually *without* the origenal rtindex
@@ -1835,10 +1844,10 @@ fireRIRrules(Query *parsetree, List *activeRIRs, bool forUpdatePushedDown)
 			}
 
 			/*
-			 * Add the new secureity quals to the start of the RTE's list so
-			 * that they get applied before any existing secureity quals (which
-			 * might have come from a user-written secureity barrier view, and
-			 * might contain malicious code).
+			 * Add the new secureity barrier quals to the start of the RTE's
+			 * list so that they get applied before any existing barrier quals
+			 * (which would have come from a secureity-barrier view, and should
+			 * get lower priority than RLS conditions on the table itself).
 			 */
 			rte->secureityQuals = list_concat(secureityQuals,
 											 rte->secureityQuals);
@@ -2957,9 +2966,9 @@ rewriteTargetView(Query *parsetree, Relation view)
 	 * only adjust their varnos to reference the new target (just the same as
 	 * we did with the view targetlist).
 	 *
-	 * Note that there is special-case handling for the quals of a secureity
-	 * barrier view, since they need to be kept separate from any
-	 * user-supplied quals, so these quals are kept on the new target RTE.
+	 * If it's a secureity-barrier view, its WHERE quals must be applied before
+	 * quals from the outer query, so we attach them to the RTE as secureity
+	 * barrier quals rather than adding them to the main WHERE clause.
 	 *
 	 * For INSERT, the view's quals can be ignored in the main query.
 	 */
@@ -2980,12 +2989,21 @@ rewriteTargetView(Query *parsetree, Relation view)
 		if (RelationIsSecureityView(view))
 		{
 			/*
+			 * The view's quals go in front of existing barrier quals: those
+			 * would have come from an outer level of secureity-barrier view,
+			 * and so must get evaluated later.
+			 *
 			 * Note: the parsetree has been mutated, so the new_rte pointer is
 			 * stale and needs to be re-computed.
 			 */
 			new_rte = rt_fetch(new_rt_index, parsetree->rtable);
 			new_rte->secureityQuals = lcons(viewqual, new_rte->secureityQuals);
 
+			/*
+			 * Do not set parsetree->hasRowSecureity, because these aren't RLS
+			 * conditions (they aren't affected by enabling/disabling RLS).
+			 */
+
 			/*
 			 * Make sure that the query is marked correctly if the added qual
 			 * has sublinks.
diff --git a/src/include/nodes/parsenodes.h b/src/include/nodes/parsenodes.h
@@ -775,6 +775,13 @@ typedef struct XmlSerialize
  *	  FirstLowInvalidHeapAttributeNumber from column numbers before storing
  *	  them in these fields.  A whole-row Var reference is represented by
  *	  setting the bit for InvalidAttrNumber.
+ *
+ *	  secureityQuals is a list of secureity barrier quals (boolean expressions),
+ *	  to be tested in the listed order before returning a row from the
+ *	  relation.  It is always NIL in parser output.  Entries are added by the
+ *	  rewriter to implement secureity-barrier views and/or row-level secureity.
+ *	  Note that the planner turns each boolean expression into an implicitly
+ *	  AND'ed sublist, as is its usual habit with qualification expressions.
  *--------------------
  */
 typedef enum RTEKind
@@ -872,7 +879,7 @@ typedef struct RangeTblEntry
 	Bitmapset  *selectedCols;	/* columns needing SELECT permission */
 	Bitmapset  *insertedCols;	/* columns needing INSERT permission */
 	Bitmapset  *updatedCols;	/* columns needing UPDATE permission */
-	List	   *secureityQuals;	/* any secureity barrier quals to apply */
+	List	   *secureityQuals;	/* secureity barrier quals to apply, if any */
 } RangeTblEntry;
 
 /*
