diff options
author | Stephen Frost <sfrost@snowman.net> | 2014-04-12 21:04:58 -0400 |
---|---|---|
committer | Stephen Frost <sfrost@snowman.net> | 2014-04-12 21:04:58 -0400 |
commit | 842faa714c0454d67e523f5a0b6df6500e9bc1a5 (patch) | |
tree | 1c65cbddbcf8ad84a8a5985a846f78622bac5f26 /doc/src | |
parent | 9d229f399e87d2ae7132c2e8feef317ce1479728 (diff) | |
download | postgresql-842faa714c0454d67e523f5a0b6df6500e9bc1a5.tar.gz postgresql-842faa714c0454d67e523f5a0b6df6500e9bc1a5.zip |
Make security barrier views automatically updatable
Views which are marked as security_barrier must have their quals
applied before any user-defined quals are called, to prevent
user-defined functions from being able to see rows which the
security barrier view is intended to prevent them from seeing.
Remove the restriction on security barrier views being automatically
updatable by adding a new securityQuals list to the RTE structure
which keeps track of the quals from security barrier views at each
level, independently of the user-supplied quals. When RTEs are
later discovered which have securityQuals populated, they are turned
into subquery RTEs which are marked as security_barrier to prevent
any user-supplied quals being pushed down (modulo LEAKPROOF quals).
Dean Rasheed, reviewed by Craig Ringer, Simon Riggs, KaiGai Kohei
Diffstat (limited to 'doc/src')
-rw-r--r-- | doc/src/sgml/ref/create_view.sgml | 19 |
1 files changed, 13 insertions, 6 deletions
diff --git a/doc/src/sgml/ref/create_view.sgml b/doc/src/sgml/ref/create_view.sgml index 57bfae30849..a13f1cbde35 100644 --- a/doc/src/sgml/ref/create_view.sgml +++ b/doc/src/sgml/ref/create_view.sgml @@ -323,12 +323,6 @@ CREATE VIEW vista AS SELECT text 'Hello World' AS hello; or set-returning functions. </para> </listitem> - - <listitem> - <para> - The view must not have the <literal>security_barrier</> property. - </para> - </listitem> </itemizedlist> </para> @@ -362,6 +356,19 @@ CREATE VIEW vista AS SELECT text 'Hello World' AS hello; </para> <para> + If an automatically updatable view is marked with the + <literal>security_barrier</> property then all the view's <literal>WHERE</> + conditions (and any conditions using operators which are marked as LEAKPROOF) + will always be evaluated before any conditions that a user of the view has + added. See <xref linkend="rules-privileges"> for full details. Note that, + due to this, rows which are not ultimately returned (because they do not + pass the user's <literal>WHERE</> conditions) may still end up being locked. + <command>EXPLAIN</command> can be used to see which conditions are + applied at the relation level (and therefore do not lock rows) and which are + not. + </para> + + <para> A more complex view that does not satisfy all these conditions is read-only by default: the system will not allow an insert, update, or delete on the view. You can get the effect of an updatable view by |