database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-30 11:03:19 +03:00
Code Activity

Make security barrier views automatically updatable

Browse Source 
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
This commit is contained in:
Stephen Frost
2014-04-12 21:04:58 -04:00
parent 9d229f399e
commit 842faa714c
19 changed files with 1372 additions and 102 deletions
Download Patch File Download Diff File Expand all files Collapse all files

19
doc/src/sgml/ref/create_view.sgml
View File

@ -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>
@ -361,6 +355,19 @@ CREATE VIEW vista AS SELECT text 'Hello World' AS hello;
such rows that are not visible through the view.
</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