Skip to content

Commit ce6b672

Browse files
robertmhaasrobertmhaas
committed
Make role grant system more consistent with other privileges.
Previously, membership of role A in role B could be recorded in the catalog tables only once. This meant that a new grant of role A to role B would overwrite the previous grant. For other object types, a new grant of permission on an object - in this case role A - exists along side the existing grant provided that the grantor is different. Either grant can be revoked independently of the other, and permissions remain so long as at least one grant remains. Make role grants work similarly. Previously, when granting membership in a role, the superuser could specify any role whatsoever as the grantor, but for other object types, the grantor of record must be either the owner of the object, or a role that currently has privileges to perform a similar GRANT. Implement the same scheme for role grants, treating the bootstrap superuser as the role owner since roles do not have owners. This means that attempting to revoke a grant, or admin option on a grant, can now fail if there are dependent privileges, and that CASCADE can be used to revoke these. It also means that you can't grant ADMIN OPTION on a role back to a user who granted it directly or indirectly to you, similar to how you can't give WITH GRANT OPTION on a privilege back to a role which granted it directly or indirectly to you. Previously, only the superuser could specify GRANTED BY with a user other than the current user. Relax that rule to allow the grantor to be any role whose privileges the current user posseses. This doesn't improve compatibility with what we do for other object types, where support for GRANTED BY is entirely vestigial, but it makes this feature more usable and seems to make sense to change at the same time we're changing related behaviors. Along the way, fix "ALTER GROUP group_name ADD USER user_name" to require the same privileges as "GRANT group_name TO user_name". Previously, CREATEROLE privileges were sufficient for either, but only the former form was permissible with ADMIN OPTION on the role. Now, either CREATEROLE or ADMIN OPTION on the role suffices for either spelling. Patch by me, reviewed by Stephen Frost. Discussion: http://postgr.es/m/CA+TgmoaFr-RZeQ+WoQ5nKPv97oT9+aDgK_a5+qWHSgbDsMp1Vg@mail.gmail.com
1 parent 36f729e commit ce6b672

File tree

15 files changed

+834
-140
lines changed

15 files changed

+834
-140
lines changed

‎doc/src/sgml/ref/alter_group.sgml

Lines changed: 5 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -52,7 +52,11 @@ ALTER GROUP <replaceable class="parameter">group_name</replaceable> RENAME TO <r
5252
equivalent to granting or revoking membership in the role named as the
5353
<quote>group</quote>; so the preferred way to do this is to use
5454
<link linkend="sql-grant"><command>GRANT</command></link> or
55-
<link linkend="sql-revoke"><command>REVOKE</command></link>.
55+
<link linkend="sql-revoke"><command>REVOKE</command></link>. Note that
56+
<command>GRANT</command> and <command>REVOKE</command> have additional
57+
options which are not available with this command, such as the ability
58+
to grant and revoke <literal>ADMIN OPTION</literal>, and the ability to
59+
specify the grantor.
5660
</para>
5761

5862
<para>

‎doc/src/sgml/ref/grant.sgml

Lines changed: 9 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -267,8 +267,14 @@ GRANT <replaceable class="parameter">role_name</replaceable> [, ...] TO <replace
267267

268268
<para>
269269
If <literal>GRANTED BY</literal> is specified, the grant is recorded as
270-
having been done by the specified role. Only database superusers may
271-
use this option, except when it names the same role executing the command.
270+
having been done by the specified role. A user can only attribute a grant
271+
to another role if they possess the privileges of that role. The role
272+
recorded as the grantor must have <literal>ADMIN OPTION</literal> on the
273+
target role, unless it is the bootstrap superuser. When a grant is recorded
274+
as having a grantor other than the bootstrap superuser, it depends on the
275+
grantor continuing to posess <literal>ADMIN OPTION</literal> on the role;
276+
so, if <literal>ADMIN OPTION</literal> is revoked, dependent grants must
277+
be revoked as well.
272278
</para>
273279

274280
<para>
@@ -333,7 +339,7 @@ GRANT <replaceable class="parameter">role_name</replaceable> [, ...] TO <replace
333339
owner of the affected object. In particular, privileges granted via
334340
such a command will appear to have been granted by the object owner.
335341
(For role membership, the membership appears to have been granted
336-
by the containing role itself.)
342+
by the bootstrap superuser.)
337343
</para>
338344

339345
<para>

‎doc/src/sgml/ref/revoke.sgml

Lines changed: 8 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -198,9 +198,10 @@ REVOKE [ ADMIN OPTION FOR ]
198198
<para>
199199
When revoking membership in a role, <literal>GRANT OPTION</literal> is instead
200200
called <literal>ADMIN OPTION</literal>, but the behavior is similar.
201-
This form of the command also allows a <literal>GRANTED BY</literal>
202-
option, but that option is currently ignored (except for checking
203-
the existence of the named role).
201+
Note that, in releases prior to <productname>PostgreSQL</productname> 16,
202+
dependent privileges were not tracked for grants of role membership,
203+
and thus <literal>CASCADE</literal> had no effect for role membership.
204+
This is no longer the case.
204205
Note also that this form of the command does not
205206
allow the noise word <literal>GROUP</literal>
206207
in <replaceable class="parameter">role_specification</replaceable>.
@@ -239,7 +240,10 @@ REVOKE [ ADMIN OPTION FOR ]
239240
<para>
240241
If a superuser chooses to issue a <command>GRANT</command> or <command>REVOKE</command>
241242
command, the command is performed as though it were issued by the
242-
owner of the affected object. Since all privileges ultimately come
243+
owner of the affected object. (Since roles do not have owners, in the
244+
case of a <command>GRANT</command> of role membership, the command is
245+
performed as though it were issued by the bootstrap superuser.)
246+
Since all privileges ultimately come
243247
from the object owner (possibly indirectly via chains of grant options),
244248
it is possible for a superuser to revoke all privileges, but this might
245249
require use of <literal>CASCADE</literal> as stated above.

0 commit comments

Comments
 (0)