1
0
mirror of https://github.com/postgres/postgres.git synced 2025-08-31 17:02:12 +03:00
Files
postgres/doc/src/sgml/ref/alter_group.sgml
Robert Haas ce6b672e44 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
2022-08-22 11:35:17 -04:00

140 lines
3.8 KiB
Plaintext

<!--
doc/src/sgml/ref/alter_group.sgml
PostgreSQL documentation
-->
<refentry id="sql-altergroup">
<indexterm zone="sql-altergroup">
<primary>ALTER GROUP</primary>
</indexterm>
<refmeta>
<refentrytitle>ALTER GROUP</refentrytitle>
<manvolnum>7</manvolnum>
<refmiscinfo>SQL - Language Statements</refmiscinfo>
</refmeta>
<refnamediv>
<refname>ALTER GROUP</refname>
<refpurpose>change role name or membership</refpurpose>
</refnamediv>
<refsynopsisdiv>
<synopsis>
ALTER GROUP <replaceable class="parameter">role_specification</replaceable> ADD USER <replaceable class="parameter">user_name</replaceable> [, ... ]
ALTER GROUP <replaceable class="parameter">role_specification</replaceable> DROP USER <replaceable class="parameter">user_name</replaceable> [, ... ]
<phrase>where <replaceable class="parameter">role_specification</replaceable> can be:</phrase>
<replaceable class="parameter">role_name</replaceable>
| CURRENT_ROLE
| CURRENT_USER
| SESSION_USER
ALTER GROUP <replaceable class="parameter">group_name</replaceable> RENAME TO <replaceable>new_name</replaceable>
</synopsis>
</refsynopsisdiv>
<refsect1>
<title>Description</title>
<para>
<command>ALTER GROUP</command> changes the attributes of a user group.
This is an obsolete command, though still accepted for backwards
compatibility, because groups (and users too) have been superseded by the
more general concept of roles.
</para>
<para>
The first two variants add users to a group or remove them from a group.
(Any role can play the part of either a <quote>user</quote> or a
<quote>group</quote> for this purpose.) These variants are effectively
equivalent to granting or revoking membership in the role named as the
<quote>group</quote>; so the preferred way to do this is to use
<link linkend="sql-grant"><command>GRANT</command></link> or
<link linkend="sql-revoke"><command>REVOKE</command></link>. Note that
<command>GRANT</command> and <command>REVOKE</command> have additional
options which are not available with this command, such as the ability
to grant and revoke <literal>ADMIN OPTION</literal>, and the ability to
specify the grantor.
</para>
<para>
The third variant changes the name of the group. This is exactly
equivalent to renaming the role with
<link linkend="sql-alterrole"><command>ALTER ROLE</command></link>.
</para>
</refsect1>
<refsect1>
<title>Parameters</title>
<variablelist>
<varlistentry>
<term><replaceable class="parameter">group_name</replaceable></term>
<listitem>
<para>
The name of the group (role) to modify.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><replaceable class="parameter">user_name</replaceable></term>
<listitem>
<para>
Users (roles) that are to be added to or removed from the group.
The users must already exist; <command>ALTER GROUP</command> does not
create or drop users.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><replaceable>new_name</replaceable></term>
<listitem>
<para>
The new name of the group.
</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Examples</title>
<para>
Add users to a group:
<programlisting>
ALTER GROUP staff ADD USER karl, john;
</programlisting>
Remove a user from a group:
<programlisting>
ALTER GROUP workers DROP USER beth;
</programlisting></para>
</refsect1>
<refsect1>
<title>Compatibility</title>
<para>
There is no <command>ALTER GROUP</command> statement in the SQL
standard.
</para>
</refsect1>
<refsect1>
<title>See Also</title>
<simplelist type="inline">
<member><xref linkend="sql-grant"/></member>
<member><xref linkend="sql-revoke"/></member>
<member><xref linkend="sql-alterrole"/></member>
</simplelist>
</refsect1>
</refentry>