diff options
author | Robert Haas <rhaas@postgresql.org> | 2023-01-24 10:57:09 -0500 |
---|---|---|
committer | Robert Haas <rhaas@postgresql.org> | 2023-01-24 10:57:09 -0500 |
commit | f1358ca52dd7b8cedd29c6f2f8c163914f03ea2e (patch) | |
tree | 88920dc72fb3bfb5bd215cd10555149515e4ce23 /doc/src | |
parent | 6c6d6ba3ee2c160b53f727cf8e612014b316d6e4 (diff) | |
download | postgresql-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.sgml | 13 | ||||
-rw-r--r-- | doc/src/sgml/ref/create_role.sgml | 23 |
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, |