From 4fb13ebae6ce50cd830dd40661c1c958585f0534 Mon Sep 17 00:00:00 2001 From: steve-chavez Date: Wed, 3 May 2023 17:22:20 -0300 Subject: [PATCH] add tables to db authz --- docs/db_authz.rst | 20 ++++++++++++++++++-- 1 file changed, 18 insertions(+), 2 deletions(-) diff --git a/docs/db_authz.rst b/docs/db_authz.rst index 0659c1887..5e622b192 100644 --- a/docs/db_authz.rst +++ b/docs/db_authz.rst @@ -104,12 +104,28 @@ This allows you to change the internals of your schema and maintain backwards co .. image:: _static/db.png -Note that you must explicitly allow roles to access the exposed schemas: +You must explicitly allow roles to access the exposed schemas: .. code-block:: postgres GRANT USAGE ON SCHEMA api TO webuser; +Tables +====== + +To let web users access tables you must grant them privileges for the operations you want them to do. + +.. code-block:: postgres + + GRANT + SELECT + , INSERT + , UPDATE(message_body) + , DELETE + ON chat TO webuser; + +You can also choose on which table columns the operation is valid. In the above example, the web user can only update the ``message_body`` column. + .. _func_privs: Functions @@ -173,7 +189,7 @@ Note the ``SECURITY DEFINER`` keywords at the end of the function. See `PostgreS Views ===== -Views are invoked with the privileges of the view owner, much like stored procedures with the ``SECURITY DEFINER`` option. When created by a SUPERUSER role, all `row-level security `_ policies will be bypassed. This is an unsuitable behavior for an API schema. +Views are invoked with the privileges of the view owner, much like stored procedures with the ``SECURITY DEFINER`` option. When created by a SUPERUSER role, all `row-level security `_ policies will be bypassed. If you're on PostgreSQL >= 15, this behavior can be changed by specifying the ``security_invoker`` option.