database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-12-22 17:42:17 +03:00
Code Activity

Add a SET option to the GRANT command.

Browse Source 
Similar to how the INHERIT option controls whether or not the
permissions of the granted role are automatically available to the
grantee, the new SET permission controls whether or not the grantee
may use the SET ROLE command to assume the privileges of the granted
role.

In addition, the new SET permission controls whether or not it
is possible to transfer ownership of objects to the target role
or to create new objects owned by the target role using commands
such as CREATE DATABASE .. OWNER. We could alternatively have made
this controlled by the INHERIT option, or allow it when either
option is given. An advantage of this approach is that if you
are granted a predefined role with INHERIT TRUE, SET FALSE, you
can't go and create objects owned by that role.

The underlying theory here is that the ability to create objects
as a target role is not a privilege per se, and thus does not
depend on whether you inherit the target role's privileges. However,
it's surely something you could do anyway if you could SET ROLE
to the target role, and thus making it contingent on whether you
have that ability is reasonable.

Design review by Nathan Bossat, Wolfgang Walther, Jeff Davis,
Peter Eisentraut, and Stephen Frost.

Discussion: http://postgr.es/m/CA+Tgmob+zDSRS6JXYrgq0NWdzCXuTNzT5eK54Dn2hhgt17nm8A@mail.gmail.com
This commit is contained in:
Robert Haas
2022-11-18 12:32:50 -05:00
parent f84ff0c6d4
commit 3d14e171e9
23 changed files with 316 additions and 92 deletions
Download Patch File Download Diff File Expand all files Collapse all files

32
doc/src/sgml/ref/grant.sgml
View File

@@ -98,7 +98,7 @@ GRANT { USAGE | ALL [ PRIVILEGES ] }
[ GRANTED BY <replaceable class="parameter">role_specification</replaceable> ]
GRANT <replaceable class="parameter">role_name</replaceable> [, ...] TO <replaceable class="parameter">role_specification</replaceable> [, ...]
[ WITH { ADMIN | INHERIT } { OPTION | TRUE | FALSE } ]
[ WITH { ADMIN | INHERIT | SET } { OPTION | TRUE | FALSE } ]
[ GRANTED BY <replaceable class="parameter">role_specification</replaceable> ]
<phrase>where <replaceable class="parameter">role_specification</replaceable> can be:</phrase>
@@ -250,17 +250,17 @@ GRANT <replaceable class="parameter">role_name</replaceable> [, ...] TO <replace
<para>
This variant of the <command>GRANT</command> command grants membership
in a role to one or more other roles. Membership in a role is significant
because it conveys the privileges granted to a role to each of its
members.
because it potentially allows access to the privileges granted to a role
to each of its members, and potentially also the ability to make changes
to the role itself. However, the actualy permisions conferred depend on
the options associated with the grant.
</para>
<para>
The effect of membership in a role can be modified by specifying the
<literal>ADMIN</literal> or <literal>INHERIT</literal> option, each
of which can be set to either <literal>TRUE</literal> or
<literal>FALSE</literal>. The keyword <literal>OPTION</literal> is accepted
as a synonym for <literal>TRUE</literal>, so that
<literal>WITH ADMIN OPTION</literal>
Each of the options described below can be set to either
<literal>TRUE</literal> or <literal>FALSE</literal>. The keyword
<literal>OPTION</literal> is accepted as a synonym for
<literal>TRUE</literal>, so that <literal>WITH ADMIN OPTION</literal>
is a synonym for <literal>WITH ADMIN TRUE</literal>.
</para>
@@ -272,7 +272,8 @@ GRANT <replaceable class="parameter">role_name</replaceable> [, ...] TO <replace
OPTION</literal> on itself. Database superusers can grant or revoke
membership in any role to anyone. Roles having
<literal>CREATEROLE</literal> privilege can grant or revoke membership
in any role that is not a superuser.
in any role that is not a superuser. This option defaults to
<literal>FALSE</literal>.
</para>
<para>
@@ -287,6 +288,17 @@ GRANT <replaceable class="parameter">role_name</replaceable> [, ...] TO <replace
See <link linkend="sql-createrole"><command>CREATE ROLE</command></link>.
</para>
<para>
The <literal>SET</literal> option, if it is set to
<literal>TRUE</literal>, allows the member to change to the granted
role using the
<link linkend="sql-set-role"><command>SET ROLE</command></link>
command. If a role is an indirect member of another role, it can use
<literal>SET ROLE</literal> to change to that role only if there is a
chain of grants each of which has <literal>SET TRUE</literal>.
This option defaults to <literal>TRUE</literal>.
</para>
<para>
If <literal>GRANTED BY</literal> is specified, the grant is recorded as
having been done by the specified role. A user can only attribute a grant

8
doc/src/sgml/ref/revoke.sgml
View File

@@ -125,7 +125,7 @@ REVOKE [ GRANT OPTION FOR ]
[ GRANTED BY <replaceable class="parameter">role_specification</replaceable> ]
[ CASCADE | RESTRICT ]
REVOKE [ { ADMIN | INHERIT } OPTION FOR ]
REVOKE [ { ADMIN | INHERIT | SET } OPTION FOR ]
<replaceable class="parameter">role_name</replaceable> [, ...] FROM <replaceable class="parameter">role_specification</replaceable> [, ...]
[ GRANTED BY <replaceable class="parameter">role_specification</replaceable> ]
[ CASCADE | RESTRICT ]
@@ -209,9 +209,9 @@ REVOKE [ { ADMIN | INHERIT } OPTION FOR ]
<para>
Just as <literal>ADMIN OPTION</literal> can be removed from an existing
role grant, it is also possible to revoke <literal>INHERIT OPTION</literal>.
This is equivalent to setting the value of that option to
<literal>FALSE</literal>.
role grant, it is also possible to revoke <literal>INHERIT OPTION</literal>
or <literal>SET OPTION</literal>. This is equivalent to setting the value
of the corresponding option to <literal>FALSE</literal>.
</para>
</refsect1>

9
doc/src/sgml/ref/set_role.sgml
View File

@@ -77,14 +77,17 @@ RESET ROLE
effectively drops all the privileges except for those which the target role
directly possesses or inherits. On the other hand, if the session user role
has been granted memberships <literal>WITH INHERIT FALSE</literal>, the
privileges of the granted roles can't be accessed by default. However, the
privileges of the granted roles can't be accessed by default. However, if
the role was granted <literal>WITH SET TRUE</literal>, the
session user can use <command>SET ROLE</command> to drop the privileges
assigned directly to the session user and instead acquire the privileges
available to the named role.
available to the named role. If the role was granted <literal>WITH INHERIT
FALSE, SET FALSE</literal> then the privileges of that role cannot be
exercised either with or without <literal>SET ROLE</literal>.
</para>
<para>
In particular, when a superuser chooses to <command>SET ROLE</command> to a
Note that when a superuser chooses to <command>SET ROLE</command> to a
non-superuser role, they lose their superuser privileges.
</para>