Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commitce6b672

Browse files
committed
Make role grant system more consistent with other privileges.
Previously, membership of role A in role B could be recorded in thecatalog tables only once. This meant that a new grant of role A torole B would overwrite the previous grant. For other object types, anew grant of permission on an object - in this case role A - existsalong side the existing grant provided that the grantor is different.Either grant can be revoked independently of the other, andpermissions remain so long as at least one grant remains. Make rolegrants work similarly.Previously, when granting membership in a role, the superuser couldspecify any role whatsoever as the grantor, but for other object types,the grantor of record must be either the owner of the object, or arole that currently has privileges to perform a similar GRANT.Implement the same scheme for role grants, treating the bootstrapsuperuser as the role owner since roles do not have owners. This meansthat attempting to revoke a grant, or admin option on a grant, can nowfail if there are dependent privileges, and that CASCADE can be usedto revoke these. It also means that you can't grant ADMIN OPTION ona 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 backto a role which granted it directly or indirectly to you.Previously, only the superuser could specify GRANTED BY with a userother than the current user. Relax that rule to allow the grantorto be any role whose privileges the current user posseses. Thisdoesn't improve compatibility with what we do for other object types,where support for GRANTED BY is entirely vestigial, but it makes thisfeature more usable and seems to make sense to change at the same timewe're changing related behaviors.Along the way, fix "ALTER GROUP group_name ADD USER user_name" torequire the same privileges as "GRANT group_name TO user_name".Previously, CREATEROLE privileges were sufficient for either, butonly the former form was permissible with ADMIN OPTION on the role.Now, either CREATEROLE or ADMIN OPTION on the role suffices foreither spelling.Patch by me, reviewed by Stephen Frost.Discussion:http://postgr.es/m/CA+TgmoaFr-RZeQ+WoQ5nKPv97oT9+aDgK_a5+qWHSgbDsMp1Vg@mail.gmail.com
1 parent36f729e commitce6b672

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 thecontaining role itself.)
342+
by thebootstrap 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)
[8]ページ先頭
©2009-2025 Movatter.jp