begriffs open source - ai-pg/blob - full-docs/txt/role-membership.txt

   1
   2 21.3. Role Membership #
   3
   4    It is frequently convenient to group users together to ease management
   5    of privileges: that way, privileges can be granted to, or revoked from,
   6    a group as a whole. In PostgreSQL this is done by creating a role that
   7    represents the group, and then granting membership in the group role to
   8    individual user roles.
   9
  10    To set up a group role, first create the role:
  11 CREATE ROLE name;
  12
  13    Typically a role being used as a group would not have the LOGIN
  14    attribute, though you can set it if you wish.
  15
  16    Once the group role exists, you can add and remove members using the
  17    GRANT and REVOKE commands:
  18 GRANT group_role TO role1, ... ;
  19 REVOKE group_role FROM role1, ... ;
  20
  21    You can grant membership to other group roles, too (since there isn't
  22    really any distinction between group roles and non-group roles). The
  23    database will not let you set up circular membership loops. Also, it is
  24    not permitted to grant membership in a role to PUBLIC.
  25
  26    The members of a group role can use the privileges of the role in two
  27    ways. First, member roles that have been granted membership with the
  28    SET option can do SET ROLE to temporarily “become” the group role. In
  29    this state, the database session has access to the privileges of the
  30    group role rather than the original login role, and any database
  31    objects created are considered owned by the group role, not the login
  32    role. Second, member roles that have been granted membership with the
  33    INHERIT option automatically have use of the privileges of those
  34    directly or indirectly a member of, though the chain stops at
  35    memberships lacking the inherit option. As an example, suppose we have
  36    done:
  37 CREATE ROLE joe LOGIN;
  38 CREATE ROLE admin;
  39 CREATE ROLE wheel;
  40 CREATE ROLE island;
  41 GRANT admin TO joe WITH INHERIT TRUE;
  42 GRANT wheel TO admin WITH INHERIT FALSE;
  43 GRANT island TO joe WITH INHERIT TRUE, SET FALSE;
  44
  45    Immediately after connecting as role joe, a database session will have
  46    use of privileges granted directly to joe plus any privileges granted
  47    to admin and island, because joe “inherits” those privileges. However,
  48    privileges granted to wheel are not available, because even though joe
  49    is indirectly a member of wheel, the membership is via admin which was
  50    granted using WITH INHERIT FALSE. After:
  51 SET ROLE admin;
  52
  53    the session would have use of only those privileges granted to admin,
  54    and not those granted to joe or island. After:
  55 SET ROLE wheel;
  56
  57    the session would have use of only those privileges granted to wheel,
  58    and not those granted to either joe or admin. The original privilege
  59    state can be restored with any of:
  60 SET ROLE joe;
  61 SET ROLE NONE;
  62 RESET ROLE;
  63
  64 Note
  65
  66    The SET ROLE command always allows selecting any role that the original
  67    login role is directly or indirectly a member of, provided that there
  68    is a chain of membership grants each of which has SET TRUE (which is
  69    the default). Thus, in the above example, it is not necessary to become
  70    admin before becoming wheel. On the other hand, it is not possible to
  71    become island at all; joe can only access those privileges via
  72    inheritance.
  73
  74 Note
  75
  76    In the SQL standard, there is a clear distinction between users and
  77    roles, and users do not automatically inherit privileges while roles
  78    do. This behavior can be obtained in PostgreSQL by giving roles being
  79    used as SQL roles the INHERIT attribute, while giving roles being used
  80    as SQL users the NOINHERIT attribute. However, PostgreSQL defaults to
  81    giving all roles the INHERIT attribute, for backward compatibility with
  82    pre-8.1 releases in which users always had use of permissions granted
  83    to groups they were members of.
  84
  85    The role attributes LOGIN, SUPERUSER, CREATEDB, and CREATEROLE can be
  86    thought of as special privileges, but they are never inherited as
  87    ordinary privileges on database objects are. You must actually SET ROLE
  88    to a specific role having one of these attributes in order to make use
  89    of the attribute. Continuing the above example, we might choose to
  90    grant CREATEDB and CREATEROLE to the admin role. Then a session
  91    connecting as role joe would not have these privileges immediately,
  92    only after doing SET ROLE admin.
  93
  94    To destroy a group role, use DROP ROLE:
  95 DROP ROLE name;
  96
  97    Any memberships in the group role are automatically revoked (but the
  98    member roles are not otherwise affected).