It is frequently convenient to group users together to ease management of privileges: that way, privileges can be granted to, or revoked from, a group as a whole. In <productname>PostgreSQL</productname> this is done by creating a role that represents the group, and then granting <firstterm>membership</firstterm> in the group role to individual user roles. 権限の管理を簡単にするために、ユーザをグループにまとめることはしばしば便利です。 グループ全体に対して権限を与えることも、取り消すこともできます。 PostgreSQLでは、グループを表すロールを作成することで行われます。 そして、そのグループロールに個々のユーザロールのメンバ資格を与えます。
To set up a group role, first create the role: グループロールを設定するには、まずロールを作成します。
CREATE ROLE name
;
Typically a role being used as a group would not have the <literal>LOGIN</literal>
attribute, though you can set it if you wish.
通常、グループとして使用されるロールにはLOGIN
属性を持たせません。
しかし、そうしたければ持たせることもできます。
Once the group role exists, you can add and remove members using the
<link linkend="sql-grant"><command>GRANT</command></link> and
<link linkend="sql-revoke"><command>REVOKE</command></link> commands:
グループロールをいったん作成すれば、GRANT
およびREVOKE
コマンドを使用してメンバの追加と削除を行うことができます。
GRANTgroup_role
TOrole1
, ... ; REVOKEgroup_role
FROMrole1
, ... ;
You can grant membership to other group roles, too (since there isn't
really any distinction between group roles and non-group roles). The
database will not let you set up circular membership loops. Also,
it is not permitted to grant membership in a role to
<literal>PUBLIC</literal>.
他のグループロールへのメンバ資格を与えることもできます。
(グループロールと非グループロールとの間には実際には区別がないからです。)
データベースはグループのメンバ資格がループし、循環するような設定はさせません。
また、ロール内のメンバ資格をPUBLIC
に付与することはできません。
The members of a group role can use the privileges of the role in two
ways. First, member roles that have been granted membership with the
<literal>SET</literal> option can do
<link linkend="sql-set-role"><command>SET ROLE</command></link> to
temporarily <quote>become</quote> the group role. In this state, the
database session has access to the privileges of the group role rather
than the original login role, and any database objects created are
considered owned by the group role not the login role. Second, member
roles that have been granted membership with the
<literal>INHERIT</literal> option automatically have use of the
privileges of those directly or indirectly a member of, though the
chain stops at memberships lacking the inherit option. As an example,
suppose we have done:
グループロールのメンバは、2つの方法でロールの権限を使用できます。
1つ目として、メンバ資格がSET
オプションで付与されたメンバロールは、SET
オプションを使用して、一時的にグループロール「になる」ことができます。
この状態では、データベースセッションは、元のログインロールではなくグループロールの権限にアクセスでき、作成されたデータベースオブジェクトは、ログインロールではなくグループロールによって所有されているとみなされます。
2つ目として、INHERIT
オプションでメンバ資格が付与されたメンバロールは、直接的または間接的にメンバであるメンバの権限を自動的に使用できます。ただし、この連鎖は継承オプションを持たないメンバ資格で停止します。
例えば、以下の状態を想定します。
CREATE ROLE joe LOGIN; CREATE ROLE admin; CREATE ROLE wheel; CREATE ROLE island; GRANT admin TO joe WITH INHERIT TRUE; GRANT wheel TO admin WITH INHERIT FALSE; GRANT island TO joe WITH INHERIT TRUE, SET FALSE;
Immediately after connecting as role <literal>joe</literal>, a database
session will have use of privileges granted directly to <literal>joe</literal>
plus any privileges granted to <literal>admin</literal> and
<literal>island</literal>, because <literal>joe</literal>
<quote>inherits</quote> those privileges. However, privileges
granted to <literal>wheel</literal> are not available, because even though
<literal>joe</literal> is indirectly a member of <literal>wheel</literal>, the
membership is via <literal>admin</literal> which was granted using
<literal>WITH INHERIT FALSE</literal>. After:
ロールjoe
として接続した直後、データベースはjoe
に直接付与された権限に加えて、admin
とisland
に付与された権限を「継承」するため、これらの権限を使用できます。
ただし、wheel
に付与された権限は使用できません。これは、joe
が間接的にwheel
のメンバであるにもかかわらず、メンバシップはadmin
を介して付与され、WITH INHERIT FALSE
を使用して付与されたためです。
SET ROLE admin;
the session would have use of only those privileges granted to
<literal>admin</literal>, and not those granted to <literal>joe</literal> or
<literal>island</literal>. After:
を行った後、セッションは、admin
に付与された権限のみを使用し、joe
やisland
に付与された権限は使用しません。
SET ROLE wheel;
the session would have use of only those privileges granted to
<literal>wheel</literal>, and not those granted to either <literal>joe</literal>
or <literal>admin</literal>. The original privilege state can be restored
with any of:
を行った後、セッションはwheel
に与えられた権限のみを使用できるようになり、joe
やadmin
に与えられた権限は使用できなくなります。
元の状態の権限に戻すには、以下のいずれかを行います。
SET ROLE joe; SET ROLE NONE; RESET ROLE;
The <command>SET ROLE</command> command always allows selecting any role
that the original login role is directly or indirectly a member of,
provided that there is a chain of membership grants each of which has
<literal>SET TRUE</literal> (which is the default).
Thus, in the above example, it is not necessary to become
<literal>admin</literal> before becoming <literal>wheel</literal>.
On the other hand, it is not possible to become <literal>island</literal>
at all; <literal>joe</literal> can only access those privileges via
inheritance.
メンバシップの許可の連鎖が存在し、それぞれがSET TRUE
(デフォルトです)である場合、SET ROLE
コマンドは、元のログインロールが直接的または間接的にメンバであるロールを常に選択できるようにします。
したがって、上記の例では、admin
になる前にwheel
になる必要はありません。
一方、island
になることはできません。 joe
は継承を介してのみこれらの権限にアクセスできます。
In the SQL standard, there is a clear distinction between users and roles,
and users do not automatically inherit privileges while roles do. This
behavior can be obtained in <productname>PostgreSQL</productname> by giving
roles being used as SQL roles the <literal>INHERIT</literal> attribute, while
giving roles being used as SQL users the <literal>NOINHERIT</literal> attribute.
However, <productname>PostgreSQL</productname> defaults to giving all roles
the <literal>INHERIT</literal> attribute, for backward compatibility with pre-8.1
releases in which users always had use of permissions granted to groups
they were members of.
標準SQLでは、ユーザとロールとの間に明確な違いがあり、ユーザはロールのように自動的に権限を継承することができません。
PostgreSQLでこの振舞いを実現させるには、SQLロールとして使用するロールにはINHERIT
属性を付与し、SQLユーザとして使用するロールにはNOINHERIT
属性を付与します。
しかし、8.1リリースより前との互換性を保持するために、PostgreSQLはデフォルトで、すべてのロールにINHERIT
属性を付与します。
以前は、ユーザは常にメンバとして属するグループに付与された権限を常に使用できました。
The role attributes <literal>LOGIN</literal>, <literal>SUPERUSER</literal>,
<literal>CREATEDB</literal>, and <literal>CREATEROLE</literal> can be thought of as
special privileges, but they are never inherited as ordinary privileges
on database objects are. You must actually <command>SET ROLE</command> to a
specific role having one of these attributes in order to make use of
the attribute. Continuing the above example, we might choose to
grant <literal>CREATEDB</literal> and <literal>CREATEROLE</literal> to the
<literal>admin</literal> role. Then a session connecting as role <literal>joe</literal>
would not have these privileges immediately, only after doing
<command>SET ROLE admin</command>.
LOGIN
、SUPERUSER
、CREATEDB
、およびCREATEROLE
ロール属性は、特別な権限とみなすことができますが、データベースオブジェクトに対する通常の権限のように継承されません。
こうした属性の1つを使用できるようにするためには、その属性を特定のロールに設定するように実際にSET ROLE
を行う必要があります。
上の例を続けると、admin
ロールにCREATEDB
権限とCREATEROLE
権限を付与することを選ぶことができます。
こうすると、joe
ロールとして接続するセッションでは、すぐさまこれらの権限を持ちません。
SET ROLE admin
を行った後で、この権限を持ちます。
To destroy a group role, use <link
linkend="sql-droprole"><command>DROP ROLE</command></link>:
グループロールを削除するには、DROP ROLE
を使用してください。
DROP ROLE name
;
Any memberships in the group role are automatically revoked (but the member roles are not otherwise affected). グループロール内のメンバ資格も自動的に取り上げられます。 (しかし、メンバロールには何も影響ありません。)