diff options
| author | Stephen Frost | 2015-04-27 16:29:42 +0000 |
|---|---|---|
| committer | Stephen Frost | 2015-04-27 16:29:42 +0000 |
| commit | dcbf5948e12aa60b4d6ab65b6445897dfc971e01 (patch) | |
| tree | 1409202a08f721acea729ed7851ad69130cdc469 /src/test/modules | |
| parent | 06ca28d5ab2f810ef25e718e0d71f2233542c151 (diff) | |
Improve qual pushdown for RLS and SB views
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.
Diffstat (limited to 'src/test/modules')
| -rw-r--r-- | src/test/modules/test_rls_hooks/expected/test_rls_hooks.out | 12 |
1 files changed, 5 insertions, 7 deletions
diff --git a/src/test/modules/test_rls_hooks/expected/test_rls_hooks.out b/src/test/modules/test_rls_hooks/expected/test_rls_hooks.out index 9427a6fae80..3a7a4c329f3 100644 --- a/src/test/modules/test_rls_hooks/expected/test_rls_hooks.out +++ b/src/test/modules/test_rls_hooks/expected/test_rls_hooks.out @@ -85,13 +85,11 @@ SET ROLE s1; -- restrictive hook's policy is current_user = superuser -- combined with AND, results in nothing being allowed EXPLAIN (costs off) SELECT * FROM rls_test_both; - QUERY PLAN -------------------------------------------------------- - Subquery Scan on rls_test_both - Filter: ("current_user"() = rls_test_both.username) - -> Seq Scan on rls_test_both rls_test_both_1 - Filter: ("current_user"() = supervisor) -(4 rows) + QUERY PLAN +------------------------------------------------------------------------------- + Seq Scan on rls_test_both + Filter: ((supervisor = "current_user"()) AND (username = "current_user"())) +(2 rows) SELECT * FROM rls_test_both; username | supervisor | data |
