| Документация по PostgreSQL 9.4.1 | |||
|---|---|---|---|
| Пред. | Уровень выше | Глава 20. Роли базы данных | След. |
20.3. Членство в роли
Часто бывает удобным сгруппировать пользователей для упрощения администрирования привилегий: привилегии выдаются или отзываются на всю группу. В PostgreSQL для этого создаётся роль, которая представляет группу, а затем членство (membership) в этой группе выдаётся ролям индивидуальных пользователей.
Для настройки групповой роли, сначала нужно создать саму роль:
CREATE ROLE name;
Обычно групповая роль не имеет атрибута LOGIN, хотя при желании его можно установить.
После того как групповая роль создана, в неё можно добавлять или удалять членов, используя команды GRANT и REVOKE:
GRANT group_role TO role1, ... ; REVOKE group_role FROM role1, ... ;
Можно выдавать членство в групповой роли другим групповым ролям (потому что в действительности нет никаких различий между групповыми и не групповыми ролями). База данных не позволит замкнуть предоставление членства по кругу. Также, не допускается выдача членства в роли для PUBLIC.
Члены групповой роли могут использовать её привилегии двумя способами. Во-первых, каждый член группы может явно выполнить SET ROLE, чтобы временно "стать" групповой ролью. В этом состоянии, сессия базы данных использует полномочия групповой роли, вместо оригинальной роли, под которой был выполнен вход в систему. При этом для всех создаваемых объектов базы данных владельцем считается групповая, а не оригинальная роль. Во-вторых, роли, имеющие атрибут INHERIT, автоматически используют привилегии всех ролей, членами которых они являются, в том числе и унаследованными этими ролями привилегиями. Например:
CREATE ROLE joe LOGIN INHERIT; CREATE ROLE admin NOINHERIT; CREATE ROLE wheel NOINHERIT; GRANT admin TO joe; GRANT wheel TO admin;
После подключения с ролью joe, сессия базы данных будет использовать полномочия выданные напрямую joe и привилегии выданные admin, так как joe "наследует" привилегии admin. Однако привилегии выданные wheel не будут доступны, потому что, хотя joe неявно и является членом wheel, это членство получено через роль admin, которая имеет атрибут NOINHERIT. После выполнения команды:
SET ROLE admin;
сессия будет использовать только привилегии выданные admin, привилегии выданные joe не будут доступны. После выполнения команды:
SET ROLE wheel;
сессия будет использовать только привилегии выданные wheel, привилегии joe и admin не будут доступны. Начальный набор привилегий можно вернуть любой из команд:
SET ROLE joe; SET ROLE NONE; RESET ROLE;
Замечание: Команда SET ROLE в любой момент разрешает выбрать любую роль, прямым или косвенным членом которой является оригинальная роль, под которой был выполнен вход в систему. Поэтому, в примере выше, не обязательно сначала становиться admin, перед тем как стать wheel.
Замечание: В стандарте SQL есть чёткое различие между пользователями и ролями. При этом пользователи не наследуют автоматически привилегии, а роли наследуют автоматически. Такое поведение может быть получено в PostgreSQL, если для ролей, используемых как роли в стандарте SQL, устанавливать атрибут INHERIT, а для ролей, используемых как пользователи в стандарте SQL, устанавливать атрибут NOINHERIT. Однако, в PostgreSQL все роли по умолчанию имеют атрибут INHERIT. Это сделано для обратной совместимости с версиями предшествующими 8.1, в которых пользователи всегда могли использовать привилегии групп, членами которых они являются.
Атрибуты роли LOGIN, SUPERUSER, CREATEDB и CREATEROLE можно рассматривать как особые привилегии, но они никогда не наследуются, как обычные привилегии на объекты базы данных. Необходимо через SET ROLE установить роль, имеющую один из этих атрибутов, чтобы им воспользоваться. Продолжая предыдущий пример, можно установить атрибуты CREATEDB и CREATEROLE для роли admin. Затем при входе с ролью joe, получить доступ к этим привилегиям будет возможно только после выполнения SET ROLE admin.
Для удаления групповой роли используется DROP ROLE:
DROP ROLE name;
Любое членство в групповой роли будет автоматически отозвано (в остальном на членов групповой роли это никак не повлияет). Однако, обратите внимание, что любые объекты, владельцем которых является групповая роль, предварительно должны быть удалены или переданы другим владельцам. Также любые привилегии выданные групповой роли должны быть отозваны.
| Пред. | Начало | След. |
| Атрибуты ролей | Уровень выше | Безопасность функций и триггеров |
| PostgreSQL 9.4.1 Documentation | |||
|---|---|---|---|
| Prev | Up | Chapter 20. Database Roles | Next |
20.3. Role Membership
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 PostgreSQL this is done by creating a role that represents the group, and then granting membership in the group role to individual user roles.
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 LOGIN attribute, though you can set it if you wish.
Once the group role exists, you can add and remove members using the GRANT and REVOKE commands:
GRANT group_role TO role1, ... ; REVOKE group_role FROM role1, ... ;
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 PUBLIC.
The members of a group role can use the privileges of the role in two ways. First, every member of a group can explicitly do SET ROLE to temporarily "become" 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 the INHERIT attribute automatically have use of the privileges of roles of which they are members, including any privileges inherited by those roles. As an example, suppose we have done:
CREATE ROLE joe LOGIN INHERIT; CREATE ROLE admin NOINHERIT; CREATE ROLE wheel NOINHERIT; GRANT admin TO joe; GRANT wheel TO admin;
Immediately after connecting as role joe, a database session will have use of privileges granted directly to joe plus any privileges granted to admin, because joe "inherits" admin's privileges. However, privileges granted to wheel are not available, because even though joe is indirectly a member of wheel, the membership is via admin which has the NOINHERIT attribute. After:
SET ROLE admin;
the session would have use of only those privileges granted to admin, and not those granted to joe. After:
SET ROLE wheel;
the session would have use of only those privileges granted to wheel, and not those granted to either joe or admin. The original privilege state can be restored with any of:
SET ROLE joe; SET ROLE NONE; RESET ROLE;
Note: The SET ROLE command always allows selecting any role that the original login role is directly or indirectly a member of. Thus, in the above example, it is not necessary to become admin before becoming wheel.
Note: 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 PostgreSQL by giving roles being used as SQL roles the INHERIT attribute, while giving roles being used as SQL users the NOINHERIT attribute. However, PostgreSQL defaults to giving all roles the INHERIT attribute, for backward compatibility with pre-8.1 releases in which users always had use of permissions granted to groups they were members of.
The role attributes LOGIN, SUPERUSER, CREATEDB, and CREATEROLE can be thought of as special privileges, but they are never inherited as ordinary privileges on database objects are. You must actually SET ROLE 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 CREATEDB and CREATEROLE to the admin role. Then a session connecting as role joe would not have these privileges immediately, only after doing SET ROLE admin.
To destroy a group role, use DROP ROLE:
DROP ROLE name;
Any memberships in the group role are automatically revoked (but the member roles are not otherwise affected). Note however that any objects owned by the group role must first be dropped or reassigned to other owners; and any permissions granted to the group role must be revoked.
