mirror of
https://github.com/postgres/postgres.git
synced 2026-02-20 08:20:55 -05:00
dcbf5948e1
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. |
||
|---|---|---|
| .. | ||
| expected | ||
| sql | ||
| .gitignore | ||
| Makefile | ||
| README | ||
| rls_hooks.conf | ||
| test_rls_hooks.c | ||
| test_rls_hooks.control | ||
| test_rls_hooks.h | ||
test_rls_hooks is an example of how to use the hooks provided for RLS to
define additional policies to be used.
Functions
=========
test_rls_hook_permissive(CmdType cmdtype, Relation relation)
RETURNS List*
Returns a list of policies which should be added to any existing
policies on the relation, combined with OR.
test_rls_hook_restrictive(CmdType cmdtype, Relation relation)
RETURNS List*
Returns a list of policies which should be added to any existing
policies on the relation, combined with AND.