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

Add support for security invoker views.

Browse Source 
A security invoker view checks permissions for accessing its
underlying base relations using the privileges of the user of the
view, rather than the privileges of the view owner. Additionally, if
any of the base relations are tables with RLS enabled, the policies of
the user of the view are applied, rather than those of the view owner.

This allows views to be defined without giving away additional
privileges on the underlying base relations, and matches a similar
feature available in other database systems.

It also allows views to operate more naturally with RLS, without
affecting the assignments of policies to users.

Christoph Heiss, with some additional hacking by me. Reviewed by
Laurenz Albe and Wolfgang Walther.

Discussion: https://postgr.es/m/b66dd6d6-ad3e-c6f2-8b90-47be773da240%40cybertec.at
This commit is contained in:
Dean Rasheed
2022-03-22 10:28:10 +00:00
parent f5576a21b0
commit 7faa5fc84b
20 changed files with 1240 additions and 76 deletions
Download Patch File Download Diff File Expand all files Collapse all files

13
doc/src/sgml/ref/lock.sgml
View File

@@ -174,10 +174,15 @@ LOCK [ TABLE ] [ ONLY ] <replaceable class="parameter">name</replaceable> [ * ]
</para>
<para>
The user performing the lock on the view must have the corresponding privilege
on the view. In addition the view's owner must have the relevant privileges on
the underlying base relations, but the user performing the lock does
not need any permissions on the underlying base relations.
The user performing the lock on the view must have the corresponding
privilege on the view. In addition, by default, the view's owner must
have the relevant privileges on the underlying base relations, whereas the
user performing the lock does not need any permissions on the underlying
base relations. However, if the view has
<literal>security_invoker</literal> set to <literal>true</literal>
(see <link linkend="sql-createview"><command>CREATE VIEW</command></link>),
the user performing the lock, rather than the view owner, must have the
relevant privileges on the underlying base relations.
</para>
<para>