begriffs open source - ai-pg/blob - full-docs/src/sgml/html/role-membership.html

   1 <?xml version="1.0" encoding="UTF-8" standalone="no"?>
   2 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>21.3. Role Membership</title><link rel="stylesheet" type="text/css" href="stylesheet.css" /><link rev="made" href="pgsql-docs@lists.postgresql.org" /><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot" /><link rel="prev" href="role-attributes.html" title="21.2. Role Attributes" /><link rel="next" href="role-removal.html" title="21.4. Dropping Roles" /></head><body id="docContent" class="container-fluid col-10"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="5" align="center">21.3. Role Membership</th></tr><tr><td width="10%" align="left"><a accesskey="p" href="role-attributes.html" title="21.2. Role Attributes">Prev</a> </td><td width="10%" align="left"><a accesskey="u" href="user-manag.html" title="Chapter 21. Database Roles">Up</a></td><th width="60%" align="center">Chapter 21. Database Roles</th><td width="10%" align="right"><a accesskey="h" href="index.html" title="PostgreSQL 18.0 Documentation">Home</a></td><td width="10%" align="right"> <a accesskey="n" href="role-removal.html" title="21.4. Dropping Roles">Next</a></td></tr></table><hr /></div><div class="sect1" id="ROLE-MEMBERSHIP"><div class="titlepage"><div><div><h2 class="title" style="clear: both">21.3. Role Membership <a href="#ROLE-MEMBERSHIP" class="id_link">#</a></h2></div></div></div><a id="id-1.6.8.7.2" class="indexterm"></a><p>
   3    It is frequently convenient to group users together to ease
   4    management of privileges: that way, privileges can be granted to, or
   5    revoked from, a group as a whole.  In <span class="productname">PostgreSQL</span>
   6    this is done by creating a role that represents the group, and then
   7    granting <em class="firstterm">membership</em> in the group role to individual user
   8    roles.
   9   </p><p>
  10    To set up a group role, first create the role:
  11 </p><pre class="synopsis">
  12 CREATE ROLE <em class="replaceable"><code>name</code></em>;
  13 </pre><p>
  14    Typically a role being used as a group would not have the <code class="literal">LOGIN</code>
  15    attribute, though you can set it if you wish.
  16   </p><p>
  17    Once the group role exists, you can add and remove members using the
  18    <a class="link" href="sql-grant.html" title="GRANT"><code class="command">GRANT</code></a> and
  19    <a class="link" href="sql-revoke.html" title="REVOKE"><code class="command">REVOKE</code></a> commands:
  20 </p><pre class="synopsis">
  21 GRANT <em class="replaceable"><code>group_role</code></em> TO <em class="replaceable"><code>role1</code></em>, ... ;
  22 REVOKE <em class="replaceable"><code>group_role</code></em> FROM <em class="replaceable"><code>role1</code></em>, ... ;
  23 </pre><p>
  24    You can grant membership to other group roles, too (since there isn't
  25    really any distinction between group roles and non-group roles).  The
  26    database will not let you set up circular membership loops.  Also,
  27    it is not permitted to grant membership in a role to
  28    <code class="literal">PUBLIC</code>.
  29   </p><p>
  30    The members of a group role can use the privileges of the role in two
  31    ways.  First, member roles that have been granted membership with the
  32    <code class="literal">SET</code> option can do
  33    <a class="link" href="sql-set-role.html" title="SET ROLE"><code class="command">SET ROLE</code></a> to
  34    temporarily <span class="quote">“<span class="quote">become</span>”</span> the group role.  In this state, the
  35    database session has access to the privileges of the group role rather
  36    than the original login role, and any database objects created are
  37    considered owned by the group role, not the login role.  Second, member
  38    roles that have been granted membership with the
  39    <code class="literal">INHERIT</code> option automatically have use of the
  40    privileges of those directly or indirectly a member of, though the
  41    chain stops at memberships lacking the inherit option.  As an example,
  42    suppose we have done:
  43 </p><pre class="programlisting">
  44 CREATE ROLE joe LOGIN;
  45 CREATE ROLE admin;
  46 CREATE ROLE wheel;
  47 CREATE ROLE island;
  48 GRANT admin TO joe WITH INHERIT TRUE;
  49 GRANT wheel TO admin WITH INHERIT FALSE;
  50 GRANT island TO joe WITH INHERIT TRUE, SET FALSE;
  51 </pre><p>
  52    Immediately after connecting as role <code class="literal">joe</code>, a database
  53    session will have use of privileges granted directly to <code class="literal">joe</code>
  54    plus any privileges granted to <code class="literal">admin</code> and
  55    <code class="literal">island</code>, because <code class="literal">joe</code>
  56    <span class="quote">“<span class="quote">inherits</span>”</span> those privileges.  However, privileges
  57    granted to <code class="literal">wheel</code> are not available, because even though
  58    <code class="literal">joe</code> is indirectly a member of <code class="literal">wheel</code>, the
  59    membership is via <code class="literal">admin</code> which was granted using
  60    <code class="literal">WITH INHERIT FALSE</code>. After:
  61 </p><pre class="programlisting">
  62 SET ROLE admin;
  63 </pre><p>
  64    the session would have use of only those privileges granted to
  65    <code class="literal">admin</code>, and not those granted to <code class="literal">joe</code> or
  66    <code class="literal">island</code>.  After:
  67 </p><pre class="programlisting">
  68 SET ROLE wheel;
  69 </pre><p>
  70    the session would have use of only those privileges granted to
  71    <code class="literal">wheel</code>, and not those granted to either <code class="literal">joe</code>
  72    or <code class="literal">admin</code>.  The original privilege state can be restored
  73    with any of:
  74 </p><pre class="programlisting">
  75 SET ROLE joe;
  76 SET ROLE NONE;
  77 RESET ROLE;
  78 </pre><p>
  79   </p><div class="note"><h3 class="title">Note</h3><p>
  80     The <code class="command">SET ROLE</code> command always allows selecting any role
  81     that the original login role is directly or indirectly a member of,
  82     provided that there is a chain of membership grants each of which has
  83     <code class="literal">SET TRUE</code> (which is the default).
  84     Thus, in the above example, it is not necessary to become
  85     <code class="literal">admin</code> before becoming <code class="literal">wheel</code>.
  86     On the other hand, it is not possible to become <code class="literal">island</code>
  87     at all; <code class="literal">joe</code> can only access those privileges via
  88     inheritance.
  89    </p></div><div class="note"><h3 class="title">Note</h3><p>
  90     In the SQL standard, there is a clear distinction between users and roles,
  91     and users do not automatically inherit privileges while roles do.  This
  92     behavior can be obtained in <span class="productname">PostgreSQL</span> by giving
  93     roles being used as SQL roles the <code class="literal">INHERIT</code> attribute, while
  94     giving roles being used as SQL users the <code class="literal">NOINHERIT</code> attribute.
  95     However, <span class="productname">PostgreSQL</span> defaults to giving all roles
  96     the <code class="literal">INHERIT</code> attribute, for backward compatibility with pre-8.1
  97     releases in which users always had use of permissions granted to groups
  98     they were members of.
  99    </p></div><p>
 100    The role attributes <code class="literal">LOGIN</code>, <code class="literal">SUPERUSER</code>,
 101    <code class="literal">CREATEDB</code>, and <code class="literal">CREATEROLE</code> can be thought of as
 102    special privileges, but they are never inherited as ordinary privileges
 103    on database objects are.  You must actually <code class="command">SET ROLE</code> to a
 104    specific role having one of these attributes in order to make use of
 105    the attribute.  Continuing the above example, we might choose to
 106    grant <code class="literal">CREATEDB</code> and <code class="literal">CREATEROLE</code> to the
 107    <code class="literal">admin</code> role.  Then a session connecting as role <code class="literal">joe</code>
 108    would not have these privileges immediately, only after doing
 109    <code class="command">SET ROLE admin</code>.
 110   </p><p>
 111   </p><p>
 112    To destroy a group role, use <a class="link" href="sql-droprole.html" title="DROP ROLE"><code class="command">DROP ROLE</code></a>:
 113 </p><pre class="synopsis">
 114 DROP ROLE <em class="replaceable"><code>name</code></em>;
 115 </pre><p>
 116    Any memberships in the group role are automatically revoked (but the
 117    member roles are not otherwise affected).
 118   </p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="role-attributes.html" title="21.2. Role Attributes">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="user-manag.html" title="Chapter 21. Database Roles">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="role-removal.html" title="21.4. Dropping Roles">Next</a></td></tr><tr><td width="40%" align="left" valign="top">21.2. Role Attributes </td><td width="20%" align="center"><a accesskey="h" href="index.html" title="PostgreSQL 18.0 Documentation">Home</a></td><td width="40%" align="right" valign="top"> 21.4. Dropping Roles</td></tr></table></div></body></html>