On Thu, Jun 20, 2024 at 07:57:16PM -0700, David G. Johnston wrote:
> I like this. Losing the table turned out to be ok. Thank you.
Awesome.
> I would probably put pg_monitor first in the list.
Done.
> + A user granted this role cannot however send signals to a backend owned
> by a superuser.
>
> Remove "however", or put commas around it. I prefer the first option.
This sentence caught my eye earlier, too, because it seems to imply that a
superuser granted this role cannot signal superuser-owned backends. I
changed it to the following:
Note that this role does not permit signaling backends owned by a
superuser.
How does that sound?
> Do we really need to repeat "even without having it explicitly" everywhere?
Removed.
> + This role does not have the role attribute BYPASSRLS set.
>
> Even if it did, that attribute isn't inherited anyway...
>
> "This role is still governed by any row level security policies that may be
> in force. Consider setting the BYPASSRLS attribute on member roles."
>
> (assuming they intend it to be ALL data then doing the bypassrls even if
> they are not today using it doesn't hurt)
How does something like the following sound?
This role does not bypass row-level security (RLS) policies. If RLS is
being used, an administrator may wish to set BYPASSRLS on roles which
this role is granted to.
> pg_stat_scan_tables - This explanation leaves me wanting more. Maybe give
> an example of such a function? I think the bar is set a bit too high just
> talking about a specific lock level.
I was surprised to learn that this role only provides privileges for
functions in contrib/ modules. Anyway, added an example.
> "As these roles are able to access any file on the server file system,"
>
> We forbid running under root so this isn't really true. They do have
> operating system level access logged in as the database process owner.
> They are able to access all PostgreSQL files on the server file system and
> usually can run a wide-variety of commands on the server.
I just deleted this clause.
> "access, therefore great care should be taken"
>
> I would go with:
>
> "access. Great care should be taken"
>
> Seems more impactful as its own sentence then at the end of a long
> multi-part sentence.
Done.
> "server with COPY any other file-access functions." - s/with/using/
Done.
--
nathan
>From 70ae4e75e59fb369bb46fccb579b9dedc6c24b11 Mon Sep 17 00:00:00 2001
From: Nathan Bossart <nat...@postgresql.org>
Date: Tue, 18 Jun 2024 11:38:40 -0500
Subject: [PATCH v2 1/1] revamp predefined roles documentation
---
doc/src/sgml/config.sgml | 2 +-
doc/src/sgml/monitoring.sgml | 4 +-
doc/src/sgml/ref/checkpoint.sgml | 2 +-
doc/src/sgml/ref/reindex.sgml | 2 +-
doc/src/sgml/user-manag.sgml | 337 ++++++++++++++++---------------
5 files changed, 183 insertions(+), 164 deletions(-)
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 0c7a9082c5..03e37209e6 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -731,7 +731,7 @@ include_dir 'conf.d'
<para>
Determines the number of connection <quote>slots</quote> that are
reserved for connections by roles with privileges of the
- <link
linkend="predefined-roles-table"><literal>pg_use_reserved_connections</literal></link>
+ <xref linkend="predefined-role-pg-use-reserved-connections"/>
role. Whenever the number of free connection slots is greater than
<xref linkend="guc-superuser-reserved-connections"/> but less than or
equal to the sum of <varname>superuser_reserved_connections</varname>
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index b2ad9b446f..f30c1e53fa 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -286,8 +286,8 @@ postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34
0:00 postgres: ser
other sessions, many columns will be null. Note, however, that the
existence of a session and its general properties such as its sessions user
and database are visible to all users. Superusers and roles with
privileges of
- built-in role <literal>pg_read_all_stats</literal> (see also <xref
- linkend="predefined-roles"/>) can see all the information about all
sessions.
+ built-in role <link
linkend="predefined-role-pg-monitor"><literal>pg_read_all_stats</literal></link>
+ can see all the information about all sessions.
</para>
<table id="monitoring-stats-dynamic-views-table">
diff --git a/doc/src/sgml/ref/checkpoint.sgml b/doc/src/sgml/ref/checkpoint.sgml
index 28a1d717b8..db011a47d0 100644
--- a/doc/src/sgml/ref/checkpoint.sgml
+++ b/doc/src/sgml/ref/checkpoint.sgml
@@ -53,7 +53,7 @@ CHECKPOINT
<para>
Only superusers or users with the privileges of
- the <link
linkend="predefined-roles-table"><literal>pg_checkpoint</literal></link>
+ the <xref linkend="predefined-role-pg-checkpoint"/>
role can call <command>CHECKPOINT</command>.
</para>
</refsect1>
diff --git a/doc/src/sgml/ref/reindex.sgml b/doc/src/sgml/ref/reindex.sgml
index 2942dccf1e..dcf70d14bc 100644
--- a/doc/src/sgml/ref/reindex.sgml
+++ b/doc/src/sgml/ref/reindex.sgml
@@ -305,7 +305,7 @@ REINDEX [ ( <replaceable
class="parameter">option</replaceable> [, ...] ) ] { DA
partitioned table, such commands skip the privilege checks when processing
the individual partitions. Reindexing a schema or database requires being
the
owner of that schema or database or having privileges of the
- <link linkend="predefined-roles-table"><literal>pg_maintain</literal></link>
+ <xref linkend="predefined-role-pg-maintain"/>
role. Note specifically that it's thus
possible for non-superusers to rebuild indexes of tables owned by
other users. However, as a special exception,
diff --git a/doc/src/sgml/user-manag.sgml b/doc/src/sgml/user-manag.sgml
index 07a16247d7..aa37823be2 100644
--- a/doc/src/sgml/user-manag.sgml
+++ b/doc/src/sgml/user-manag.sgml
@@ -590,101 +590,71 @@ DROP ROLE doomed_role;
and information. Administrators (including roles that have the
<literal>CREATEROLE</literal> privilege) can <command>GRANT</command> these
roles to users and/or other roles in their environment, providing those
- users with access to the specified capabilities and information.
+ users with access to the specified capabilities and information. For
+ example:
+
+<programlisting>
+GRANT pg_signal_backend TO admin_user;
+</programlisting>
</para>
+ <warning>
+ <para>
+ Care should be taken when granting these roles to ensure they are only used
+ where needed and with the understanding that these roles grant access to
+ privileged information.
+ </para>
+ </warning>
+
<para>
- The predefined roles are described in <xref
linkend="predefined-roles-table"/>.
+ The predefined roles are described below.
Note that the specific permissions for each of the roles may change in
the future as additional capabilities are added. Administrators
should monitor the release notes for changes.
- </para>
- <table tocentry="1" id="predefined-roles-table">
- <title>Predefined Roles</title>
- <tgroup cols="2">
- <colspec colname="col1" colwidth="1*"/>
- <colspec colname="col2" colwidth="2*"/>
- <thead>
- <row>
- <entry>Role</entry>
- <entry>Allowed Access</entry>
- </row>
- </thead>
- <tbody>
- <row>
- <entry>pg_read_all_data</entry>
- <entry>Read all data (tables, views, sequences), as if having
- <command>SELECT</command> rights on those objects, and USAGE rights on
- all schemas, even without having it explicitly. This role does not have
- the role attribute <literal>BYPASSRLS</literal> set. If RLS is being
- used, an administrator may wish to set <literal>BYPASSRLS</literal> on
- roles which this role is GRANTed to.</entry>
- </row>
- <row>
- <entry>pg_write_all_data</entry>
- <entry>Write all data (tables, views, sequences), as if having
- <command>INSERT</command>, <command>UPDATE</command>, and
- <command>DELETE</command> rights on those objects, and USAGE rights on
- all schemas, even without having it explicitly. This role does not have
- the role attribute <literal>BYPASSRLS</literal> set. If RLS is being
- used, an administrator may wish to set <literal>BYPASSRLS</literal> on
- roles which this role is GRANTed to.</entry>
- </row>
- <row>
- <entry>pg_read_all_settings</entry>
- <entry>Read all configuration variables, even those normally visible
only to
- superusers.</entry>
- </row>
- <row>
- <entry>pg_read_all_stats</entry>
- <entry>Read all pg_stat_* views and use various statistics related
extensions,
- even those normally visible only to superusers.</entry>
- </row>
- <row>
- <entry>pg_stat_scan_tables</entry>
- <entry>Execute monitoring functions that may take <literal>ACCESS
SHARE</literal> locks on tables,
- potentially for a long time.</entry>
- </row>
- <row>
- <entry>pg_monitor</entry>
- <entry>Read/execute various monitoring views and functions.
- This role is a member of <literal>pg_read_all_settings</literal>,
- <literal>pg_read_all_stats</literal> and
- <literal>pg_stat_scan_tables</literal>.</entry>
- </row>
- <row>
- <entry>pg_database_owner</entry>
- <entry>None. Membership consists, implicitly, of the current database
owner.</entry>
- </row>
- <row>
- <entry>pg_signal_backend</entry>
- <entry>Signal another backend to cancel a query or terminate its
session.</entry>
- </row>
- <row>
- <entry>pg_read_server_files</entry>
- <entry>Allow reading files from any location the database can access on
the server with COPY and
- other file-access functions.</entry>
- </row>
- <row>
- <entry>pg_write_server_files</entry>
- <entry>Allow writing to files in any location the database can access
on the server with COPY and
- other file-access functions.</entry>
- </row>
- <row>
- <entry>pg_execute_server_program</entry>
- <entry>Allow executing programs on the database server as the user the
database runs as with
- COPY and other functions which allow executing a server-side
program.</entry>
- </row>
- <row>
- <entry>pg_checkpoint</entry>
- <entry>Allow executing
- the <link linkend="sql-checkpoint"><command>CHECKPOINT</command></link>
- command.</entry>
- </row>
- <row>
- <entry>pg_maintain</entry>
- <entry>Allow executing
+ <variablelist>
+ <varlistentry id="predefined-role-pg-checkpoint" xreflabel="pg_checkpoint">
+ <term><varname>pg_checkpoint</varname></term>
+ <listitem>
+ <para>
+ Allows executing the
+ <link linkend="sql-checkpoint"><command>CHECKPOINT</command></link>
command.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="predefined-role-pg-create-subscription"
xreflabel="pg_create_subscription">
+ <term><varname>pg_create_subscription</varname></term>
+ <listitem>
+ <para>
+ Allows users with <literal>CREATE</literal> permission on the database
to issue
+ <link linkend="sql-createsubscription"><command>CREATE
SUBSCRIPTION</command></link>.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="predefined-role-pg-database-owner"
xreflabel="pg_database_owner">
+ <term><varname>pg_database_owner</varname></term>
+ <listitem>
+ <para>
+ Membership consists, implicitly, of the current database owner. Like
+ any role, it can own objects or receive grants of access privileges.
+ Consequently, once <literal>pg_database_owner</literal> has rights
+ within a template database, each owner of a database instantiated from
+ that template will exercise those rights.
+ <literal>pg_database_owner</literal> cannot be a member of any role, and
+ it cannot have non-implicit members. Initially, this role owns the
+ <literal>public</literal> schema, so each database owner governs local
+ use of the schema.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="predefined-role-pg-maintain" xreflabel="pg_maintain">
+ <term><varname>pg_maintain</varname></term>
+ <listitem>
+ <para>
+ Allows executing
<link linkend="sql-vacuum"><command>VACUUM</command></link>,
<link linkend="sql-analyze"><command>ANALYZE</command></link>,
<link linkend="sql-cluster"><command>CLUSTER</command></link>,
@@ -692,78 +662,127 @@ DROP ROLE doomed_role;
<link linkend="sql-reindex"><command>REINDEX</command></link>,
and <link linkend="sql-lock"><command>LOCK TABLE</command></link> on all
relations, as if having <literal>MAINTAIN</literal> rights on those
- objects, even without having it explicitly.</entry>
- </row>
- <row>
- <entry>pg_use_reserved_connections</entry>
- <entry>Allow use of connection slots reserved via
- <xref linkend="guc-reserved-connections"/>.</entry>
- </row>
- <row>
- <entry>pg_create_subscription</entry>
- <entry>Allow users with <literal>CREATE</literal> permission on the
- database to issue
- <link linkend="sql-createsubscription"><command>CREATE
SUBSCRIPTION</command></link>.</entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- <para>
- The <literal>pg_monitor</literal>, <literal>pg_read_all_settings</literal>,
- <literal>pg_read_all_stats</literal> and
<literal>pg_stat_scan_tables</literal>
- roles are intended to allow administrators to easily configure a role for the
- purpose of monitoring the database server. They grant a set of common
privileges
- allowing the role to read various useful configuration settings, statistics
and
- other system information normally restricted to superusers.
- </para>
-
- <para>
- The <literal>pg_database_owner</literal> role has one implicit,
- situation-dependent member, namely the owner of the current database. Like
- any role, it can own objects or receive grants of access privileges.
- Consequently, once <literal>pg_database_owner</literal> has rights within a
- template database, each owner of a database instantiated from that template
- will exercise those rights. <literal>pg_database_owner</literal> cannot be
- a member of any role, and it cannot have non-implicit members. Initially,
- this role owns the <literal>public</literal> schema, so each database owner
- governs local use of the schema.
- </para>
-
- <para>
- The <literal>pg_signal_backend</literal> role is intended to allow
- administrators to enable trusted, but non-superuser, roles to send signals
- to other backends. Currently this role enables sending of signals for
- canceling a query on another backend or terminating its session. A user
- granted this role cannot however send signals to a backend owned by a
- superuser. See <xref linkend="functions-admin-signal"/>.
- </para>
-
- <para>
- The <literal>pg_read_server_files</literal>,
<literal>pg_write_server_files</literal> and
- <literal>pg_execute_server_program</literal> roles are intended to allow
administrators to have
- trusted, but non-superuser, roles which are able to access files and run
programs on the
- database server as the user the database runs as. As these roles are able
to access any file on
- the server file system, they bypass all database-level permission checks
when accessing files
- directly and they could be used to gain superuser-level access, therefore
- great care should be taken when granting these roles to users.
- </para>
-
- <para>
- Care should be taken when granting these roles to ensure they are only used
where
- needed and with the understanding that these roles grant access to privileged
- information.
- </para>
-
- <para>
- Administrators can grant access to these roles to users using the
- <link linkend="sql-grant"><command>GRANT</command></link> command, for
example:
-
-<programlisting>
-GRANT pg_signal_backend TO admin_user;
-</programlisting>
+ objects.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="predefined-role-pg-monitor" xreflabel="pg_monitor">
+ <term><varname>pg_monitor</varname></term>
+ <term><varname>pg_read_all_settings</varname></term>
+ <term><varname>pg_read_all_stats</varname></term>
+ <term><varname>pg_stat_scan_tables</varname></term>
+ <listitem>
+ <para>
+ These roles are intended to allow administrators to easily configure a
+ role for the purpose of monitoring the database server. They grant a
+ set of common privileges allowing the role to read various useful
+ configuration settings, statistics, and other system information
+ normally restricted to superusers.
+ </para>
+ <para>
+ <literal>pg_monitor</literal> allows reading/executing various
+ monitoring views and functions. This role is a member of
+ <literal>pg_read_all_settings</literal>,
+ <literal>pg_read_all_stats</literal> and
+ <literal>pg_stat_scan_tables</literal>.
+ </para>
+ <para>
+ <literal>pg_read_all_settings</literal> allows reading all configuration
+ variables, even those normally visible only to superusers.
+ </para>
+ <para>
+ <literal>pg_read_all_stats</literal> allows reading all pg_stat_* views
+ and use various statistics related extensions, even those normally
+ visible only to superusers.
+ </para>
+ <para>
+ <literal>pg_stat_scan_tables</literal> allows executing monitoring
+ functions that may take <literal>ACCESS SHARE</literal> locks on tables,
+ potentially for a long time (e.g., <function>pgrowlocks(text)</function>
+ in the <xref linkend="pgrowlocks"/> extension).
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="predefined-role-pg-read-all-data"
xreflabel="pg_read_all_data">
+ <term><varname>pg_read_all_data</varname></term>
+ <term><varname>pg_write_all_data</varname></term>
+ <listitem>
+ <para>
+ <literal>pg_read_all_data</literal> allows reading all data (tables,
+ views, sequences), as if having <command>SELECT</command> rights on
+ those objects and <literal>USAGE</literal> rights on all schemas. This
+ role does not bypass row-level security (RLS) policies. If RLS is being
+ used, an administrator may wish to set <literal>BYPASSRLS</literal> on
+ roles which this role is granted to.
+ </para>
+ <para>
+ <literal>pg_write_all_data</literal> allows writing all data (tables,
+ views, sequences), as if having <command>INSERT</command>,
+ <command>UPDATE</command>, and <command>DELETE</command> rights on those
+ objects and <literal>USAGE</literal> rights on all schemas. This role
+ does not bypass row-level security (RLS) policies. If RLS is being
+ used, an administrator may wish to set <literal>BYPASSRLS</literal> on
+ roles which this role is granted to.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="predefined-role-pg-read-server-files"
xreflabel="pg_read_server_files">
+ <term><varname>pg_read_server_files</varname></term>
+ <term><varname>pg_write_server_files</varname></term>
+ <term><varname>pg_execute_server_program</varname></term>
+ <listitem>
+ <para>
+ These roles are intended to allow administrators to have trusted, but
+ non-superuser, roles which are able to access files and run programs on
+ the database server as the user the database runs as. They bypass all
+ database-level permission checks when accessing files directly and they
+ could be used to gain superuser-level access. Therefore, great care
+ should be taken when granting these roles to users.
+ </para>
+ <para>
+ <literal>pg_read_server_files</literal> allows reading files from any
+ location the database can access on the server using
+ <command>COPY</command> and other file-access functions.
+ </para>
+ <para>
+ <literal>pg_write_server_files</literal> allows writing to files in any
+ location the database can access on the server using
+ <command>COPY</command> and other file-access functions.
+ </para>
+ <para>
+ <literal>pg_execute_server_program</literal> allows executing programs
+ on the database server as the user the database runs as using
+ <command>COPY</command> and other functions which allow executing a
+ server-side program.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="predefined-role-pg-signal-backend"
xreflabel="pg_signal_backend">
+ <term><varname>pg_signal_backend</varname></term>
+ <listitem>
+ <para>
+ Allows signaling another backend to cancel a query or terminate its
+ session. Note that this role does not permit signaling backends owned
+ by a superuser. See <xref linkend="functions-admin-signal"/>.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="predefined-role-pg-use-reserved-connections"
xreflabel="pg_use_reserved_connections">
+ <term><varname>pg_use_reserved_connections</varname></term>
+ <listitem>
+ <para>
+ Allows use of connection slots reserved via
+ <xref linkend="guc-reserved-connections"/>.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
</para>
-
</sect1>
<sect1 id="perm-functions">
--
2.39.3 (Apple Git-146)
