summaryrefslogtreecommitdiff
path: root/doc/src
diff options
context:
space:
mode:
authorRobert Haas <rhaas@postgresql.org>2023-01-24 10:57:09 -0500
committerRobert Haas <rhaas@postgresql.org>2023-01-24 10:57:09 -0500
commitf1358ca52dd7b8cedd29c6f2f8c163914f03ea2e (patch)
tree88920dc72fb3bfb5bd215cd10555149515e4ce23 /doc/src
parent6c6d6ba3ee2c160b53f727cf8e612014b316d6e4 (diff)
downloadpostgresql-f1358ca52dd7b8cedd29c6f2f8c163914f03ea2e.tar.gz
Adjust interaction of CREATEROLE with role properties.
Previously, a CREATEROLE user without SUPERUSER could not alter REPLICATION users in any way, and could not set the BYPASSRLS attribute. However, they could manipulate the CREATEDB property even if they themselves did not possess it. With this change, a CREATEROLE user without SUPERUSER can set or clear the REPLICATION, BYPASSRLS, or CREATEDB property on a new role or a role that they have rights to manage if and only if that property is set for their own role. This implements the standard idea that you can't give permissions you don't have (but you can give the ones you do have). We might in the future want to provide more powerful ways to constrain what a CREATEROLE user can do - for example, to limit whether CONNECTION LIMIT can be set or the values to which it can be set - but that is left as future work. Patch by me, reviewed by Nathan Bossart, Tushar Ahuja, and Neha Sharma. Discussion: http://postgr.es/m/CA+TgmobX=LHg_J5aT=0pi9gJy=JdtrUVGAu0zhr-i5v5nNbJDg@mail.gmail.com
Diffstat (limited to 'doc/src')
-rw-r--r--doc/src/sgml/ref/alter_role.sgml13
-rw-r--r--doc/src/sgml/ref/create_role.sgml23
2 files changed, 14 insertions, 22 deletions
diff --git a/doc/src/sgml/ref/alter_role.sgml b/doc/src/sgml/ref/alter_role.sgml
index fbb4612e70..ff2b88e9b6 100644
--- a/doc/src/sgml/ref/alter_role.sgml
+++ b/doc/src/sgml/ref/alter_role.sgml
@@ -70,11 +70,14 @@ ALTER ROLE { <replaceable class="parameter">role_specification</replaceable> | A
<link linkend="sql-revoke"><command>REVOKE</command></link> for that.)
Attributes not mentioned in the command retain their previous settings.
Database superusers can change any of these settings for any role.
- Roles having <literal>CREATEROLE</literal> privilege can change any of these
- settings except <literal>SUPERUSER</literal>, <literal>REPLICATION</literal>,
- and <literal>BYPASSRLS</literal>; but only for non-superuser and
- non-replication roles for which they have been
- granted <literal>ADMIN OPTION</literal>.
+ Non-superuser roles having <literal>CREATEROLE</literal> privilege can
+ change most of these properties, but only for non-superuser and
+ non-replication roles for which they have been granted
+ <literal>ADMIN OPTION</literal>. Non-superusers cannot change the
+ <literal>SUPERUSER</literal> property and can change the
+ <literal>CREATEDB</literal>, <literal>REPLICATION</literal>, and
+ <literal>BYPASSRLS</literal> properties only if they possess the
+ corresponding property themselves.
Ordinary roles can only change their own password.
</para>
diff --git a/doc/src/sgml/ref/create_role.sgml b/doc/src/sgml/ref/create_role.sgml
index 7ce4e38b45..c101df6e2f 100644
--- a/doc/src/sgml/ref/create_role.sgml
+++ b/doc/src/sgml/ref/create_role.sgml
@@ -109,6 +109,8 @@ in sync when changing the above synopsis!
<literal>NOCREATEDB</literal> will deny a role the ability to
create databases. If not specified,
<literal>NOCREATEDB</literal> is the default.
+ Only superuser roles or roles with <literal>CREATEDB</literal>
+ can specify <literal>CREATEDB</literal>.
</para>
</listitem>
</varlistentry>
@@ -188,8 +190,8 @@ in sync when changing the above synopsis!
highly privileged role, and should only be used on roles actually
used for replication. If not specified,
<literal>NOREPLICATION</literal> is the default.
- You must be a superuser to create a new role having the
- <literal>REPLICATION</literal> attribute.
+ Only superuser roles or roles with <literal>REPLICATION</literal>
+ can specify <literal>REPLICATION</literal>.
</para>
</listitem>
</varlistentry>
@@ -201,8 +203,8 @@ in sync when changing the above synopsis!
<para>
These clauses determine whether a role bypasses every row-level
security (RLS) policy. <literal>NOBYPASSRLS</literal> is the default.
- You must be a superuser to create a new role having
- the <literal>BYPASSRLS</literal> attribute.
+ Only superuser roles or roles with <literal>BYPASSRLS</literal>
+ can specify <literal>BYPASSRLS</literal>.
</para>
<para>
@@ -391,19 +393,6 @@ in sync when changing the above synopsis!
</para>
<para>
- Be careful with the <literal>CREATEROLE</literal> privilege. There is no concept of
- inheritance for the privileges of a <literal>CREATEROLE</literal>-role. That
- means that even if a role does not have a certain privilege but is allowed
- to create other roles, it can easily create another role with different
- privileges than its own (except for creating roles with superuser
- privileges). For example, if the role <quote>user</quote> has the
- <literal>CREATEROLE</literal> privilege but not the <literal>CREATEDB</literal> privilege,
- nonetheless it can create a new role with the <literal>CREATEDB</literal>
- privilege. Therefore, regard roles that have the <literal>CREATEROLE</literal>
- privilege as almost-superuser-roles.
- </para>
-
- <para>
<productname>PostgreSQL</productname> includes a program <xref
linkend="app-createuser"/> that has
the same functionality as <command>CREATE ROLE</command> (in fact,