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

   1
   2 21.2. Role Attributes #
   3
   4    A database role can have a number of attributes that define its
   5    privileges and interact with the client authentication system.
   6
   7    login privilege
   8           Only roles that have the LOGIN attribute can be used as the
   9           initial role name for a database connection. A role with the
  10           LOGIN attribute can be considered the same as a “database user”.
  11           To create a role with login privilege, use either:
  12
  13 CREATE ROLE name LOGIN;
  14 CREATE USER name;
  15
  16           (CREATE USER is equivalent to CREATE ROLE except that CREATE
  17           USER includes LOGIN by default, while CREATE ROLE does not.)
  18
  19    superuser status
  20           A database superuser bypasses all permission checks, except the
  21           right to log in. This is a dangerous privilege and should not be
  22           used carelessly; it is best to do most of your work as a role
  23           that is not a superuser. To create a new database superuser, use
  24           CREATE ROLE name SUPERUSER. You must do this as a role that is
  25           already a superuser.
  26
  27    database creation
  28           A role must be explicitly given permission to create databases
  29           (except for superusers, since those bypass all permission
  30           checks). To create such a role, use CREATE ROLE name CREATEDB.
  31
  32    role creation
  33           A role must be explicitly given permission to create more roles
  34           (except for superusers, since those bypass all permission
  35           checks). To create such a role, use CREATE ROLE name CREATEROLE.
  36           A role with CREATEROLE privilege can alter and drop roles which
  37           have been granted to the CREATEROLE user with the ADMIN option.
  38           Such a grant occurs automatically when a CREATEROLE user that is
  39           not a superuser creates a new role, so that by default, a
  40           CREATEROLE user can alter and drop the roles which they have
  41           created. Altering a role includes most changes that can be made
  42           using ALTER ROLE, including, for example, changing passwords. It
  43           also includes modifications to a role that can be made using the
  44           COMMENT and SECURITY LABEL commands.
  45
  46           However, CREATEROLE does not convey the ability to create
  47           SUPERUSER roles, nor does it convey any power over SUPERUSER
  48           roles that already exist. Furthermore, CREATEROLE does not
  49           convey the power to create REPLICATION users, nor the ability to
  50           grant or revoke the REPLICATION privilege, nor the ability to
  51           modify the role properties of such users. However, it does allow
  52           ALTER ROLE ... SET and ALTER ROLE ... RENAME to be used on
  53           REPLICATION roles, as well as the use of COMMENT ON ROLE,
  54           SECURITY LABEL ON ROLE, and DROP ROLE. Finally, CREATEROLE does
  55           not confer the ability to grant or revoke the BYPASSRLS
  56           privilege.
  57
  58    initiating replication
  59           A role must explicitly be given permission to initiate streaming
  60           replication (except for superusers, since those bypass all
  61           permission checks). A role used for streaming replication must
  62           have LOGIN permission as well. To create such a role, use CREATE
  63           ROLE name REPLICATION LOGIN.
  64
  65    password
  66           A password is only significant if the client authentication
  67           method requires the user to supply a password when connecting to
  68           the database. The password and md5 authentication methods make
  69           use of passwords. Database passwords are separate from operating
  70           system passwords. Specify a password upon role creation with
  71           CREATE ROLE name PASSWORD 'string'.
  72
  73    inheritance of privileges
  74           A role inherits the privileges of roles it is a member of, by
  75           default. However, to create a role which does not inherit
  76           privileges by default, use CREATE ROLE name NOINHERIT.
  77           Alternatively, inheritance can be overridden for individual
  78           grants by using WITH INHERIT TRUE or WITH INHERIT FALSE.
  79
  80    bypassing row-level security
  81           A role must be explicitly given permission to bypass every
  82           row-level security (RLS) policy (except for superusers, since
  83           those bypass all permission checks). To create such a role, use
  84           CREATE ROLE name BYPASSRLS as a superuser.
  85
  86    connection limit
  87           Connection limit can specify how many concurrent connections a
  88           role can make. -1 (the default) means no limit. Specify
  89           connection limit upon role creation with CREATE ROLE name
  90           CONNECTION LIMIT 'integer'.
  91
  92    A role's attributes can be modified after creation with ALTER ROLE. See
  93    the reference pages for the CREATE ROLE and ALTER ROLE commands for
  94    details.
  95
  96    A role can also have role-specific defaults for many of the run-time
  97    configuration settings described in Chapter 19. For example, if for
  98    some reason you want to disable index scans (hint: not a good idea)
  99    anytime you connect, you can use:
 100 ALTER ROLE myname SET enable_indexscan TO off;
 101
 102    This will save the setting (but not set it immediately). In subsequent
 103    connections by this role it will appear as though SET enable_indexscan
 104    TO off had been executed just before the session started. You can still
 105    alter this setting during the session; it will only be the default. To
 106    remove a role-specific default setting, use ALTER ROLE rolename RESET
 107    varname. Note that role-specific defaults attached to roles without
 108    LOGIN privilege are fairly useless, since they will never be invoked.
 109
 110    When a non-superuser creates a role using the CREATEROLE privilege, the
 111    created role is automatically granted back to the creating user, just
 112    as if the bootstrap superuser had executed the command GRANT
 113    created_user TO creating_user WITH ADMIN TRUE, SET FALSE, INHERIT
 114    FALSE. Since a CREATEROLE user can only exercise special privileges
 115    with regard to an existing role if they have ADMIN OPTION on it, this
 116    grant is just sufficient to allow a CREATEROLE user to administer the
 117    roles they created. However, because it is created with INHERIT FALSE,
 118    SET FALSE, the CREATEROLE user doesn't inherit the privileges of the
 119    created role, nor can it access the privileges of that role using SET
 120    ROLE. However, since any user who has ADMIN OPTION on a role can grant
 121    membership in that role to any other user, the CREATEROLE user can gain
 122    access to the created role by simply granting that role back to
 123    themselves with the INHERIT and/or SET options. Thus, the fact that
 124    privileges are not inherited by default nor is SET ROLE granted by
 125    default is a safeguard against accidents, not a security feature. Also
 126    note that, because this automatic grant is granted by the bootstrap
 127    superuser, it cannot be removed or changed by the CREATEROLE user;
 128    however, any superuser could revoke it, modify it, and/or issue
 129    additional such grants to other CREATEROLE users. Whichever CREATEROLE
 130    users have ADMIN OPTION on a role at any given time can administer it.