database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-06-23 14:01:44 +03:00
Code Activity

Improve qual pushdown for RLS and SB views

Browse Source 
The original security barrier view implementation, on which RLS is
built, prevented all non-leakproof functions from being pushed down to
below the view, even when the function was not receiving any data from
the view.  This optimization improves on that situation by, instead of
checking strictly for non-leakproof functions, it checks for Vars being
passed to non-leakproof functions and allows functions which do not
accept arguments or whose arguments are not from the current query level
(eg: constants can be particularly useful) to be pushed down.

As discussed, this does mean that a function which is pushed down might
gain some idea that there are rows meeting a certain criteria based on
the number of times the function is called, but this isn't a
particularly new issue and the documentation in rules.sgml already
addressed similar covert-channel risks.  That documentation is updated
to reflect that non-leakproof functions may be pushed down now, if
they meet the above-described criteria.

Author: Dean Rasheed, with a bit of rework to make things clearer,
along with comment and documentation updates from me.
This commit is contained in:
Stephen Frost
2015-04-27 12:29:42 -04:00
parent 06ca28d5ab
commit dcbf5948e1
10 changed files with 320 additions and 39 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
doc/src/sgml/rules.sgml
View File

@ -2136,7 +2136,7 @@ SELECT * FROM phone_number WHERE tricky(person, phone);
When it is necessary for a view to provide row level security, the
<literal>security_barrier</literal> attribute should be applied to
the view. This prevents maliciously-chosen functions and operators from
being invoked on rows until after the view has done its work. For
being passed values from rows until after the view has done its work. For
example, if the view shown above had been created like this, it would
be secure:
<programlisting>
@ -2157,9 +2157,12 @@ CREATE VIEW phone_number WITH (security_barrier) AS
operators. The query planner can safely allow such functions to be evaluated
at any point in the query execution process, since invoking them on rows
invisible to the user will not leak any information about the unseen rows.
In contrast, a function that might throw an error depending on the values
received as arguments (such as one that throws an error in the event of
overflow or division by zero) are not leak-proof, and could provide
Further, functions which do not take arguments or which are not passed any
arguments from the security barrier view do not have to be marked as
<literal>LEAKPROOF</literal> to be pushed down, as they never receive data
from the view. In contrast, a function that might throw an error depending
on the values received as arguments (such as one that throws an error in the
event of overflow or division by zero) are not leak-proof, and could provide
significant information about the unseen rows if applied before the security
view's row filters.
</para>