rdelaage
/
postgresql
mirror of https://git.postgresql.org/git/postgresql.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
postgresql/doc/src/sgml/ref/create_role.sgml

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

517 lines
20 KiB
Plaintext
Raw Normal View History

Basic documentation for ROLEs. The user-manag chapter still needs to be rewritten, but at least the reference pages are reasonably sane.
2005-07-27 01:24:02 +02:00
<!--
Remove cvs keywords from all files.
2010-09-20 22:08:53 +02:00
doc/src/sgml/ref/create_role.sgml
Basic documentation for ROLEs. The user-manag chapter still needs to be rewritten, but at least the reference pages are reasonably sane.
2005-07-27 01:24:02 +02:00
PostgreSQL documentation
-->
Convert SGML IDs to lower case IDs in SGML are case insensitive, and we have accumulated a mix of upper and lower case IDs, including different variants of the same ID. In XML, these will be case sensitive, so we need to fix up those differences. Going to all lower case seems most straightforward, and the current build process already makes all anchors and lower case anyway during the SGML->XML conversion, so this doesn't create any difference in the output right now. A future XML-only build process would, however, maintain any mixed case ID spellings in the output, so that is another reason to clean this up beforehand. Author: Alexander Lakhin <exclusion@gmail.com>
2017-10-20 03:16:39 +02:00
<refentry id="sql-createrole">
doc: Improve DocBook XML validity DocBook XML is superficially compatible with DocBook SGML but has a slightly stricter DTD that we have been violating in a few cases. Although XSLT doesn't care whether the document is valid, the style sheets don't necessarily process invalid documents correctly, so we need to work toward fixing this. This first commit moves the indexterms in refentry elements to an allowed position. It has no impact on the output.
2014-02-24 03:25:35 +01:00
<indexterm zone="sql-createrole">
<primary>CREATE ROLE</primary>
</indexterm>
Basic documentation for ROLEs. The user-manag chapter still needs to be rewritten, but at least the reference pages are reasonably sane.
2005-07-27 01:24:02 +02:00
<refmeta>
Remove unnecessary xref endterm attributes and title ids The endterm attribute is mainly useful when the toolchain does not support automatic link target text generation for a particular situation. In the past, this was required by the man page tools for all reference page links, but that is no longer the case, and it now actually gets in the way of proper automatic link text generation. The only remaining use cases are currently xrefs to refsects.
2010-04-03 09:23:02 +02:00
<refentrytitle>CREATE ROLE</refentrytitle>
Set SQL man pages to be section 7 by default, and only transform them to another section if required by the platform (instead of the old way of building them in section "l" and always transforming them to the platform-specific section). This speeds up the installation on common platforms, and it avoids some funny business with the man page tools and build process.
2008-11-14 11:22:48 +01:00
<manvolnum>7</manvolnum>
Basic documentation for ROLEs. The user-manag chapter still needs to be rewritten, but at least the reference pages are reasonably sane.
2005-07-27 01:24:02 +02:00
<refmiscinfo>SQL - Language Statements</refmiscinfo>
</refmeta>
<refnamediv>
<refname>CREATE ROLE</refname>
<refpurpose>define a new database role</refpurpose>
</refnamediv>
<refsynopsisdiv>
<synopsis>
Use lower-case SGML attribute values for DocBook XML compatibility
2017-10-09 04:00:57 +02:00
CREATE ROLE <replaceable class="parameter">name</replaceable> [ [ WITH ] <replaceable class="parameter">option</replaceable> [ ... ] ]
Basic documentation for ROLEs. The user-manag chapter still needs to be rewritten, but at least the reference pages are reasonably sane.
2005-07-27 01:24:02 +02:00
Use lower-case SGML attribute values for DocBook XML compatibility
2017-10-09 04:00:57 +02:00
<phrase>where <replaceable class="parameter">option</replaceable> can be:</phrase>
Remove useless whitespace at end of lines
2010-11-23 21:27:50 +01:00
Basic documentation for ROLEs. The user-manag chapter still needs to be rewritten, but at least the reference pages are reasonably sane.
2005-07-27 01:24:02 +02:00
SUPERUSER | NOSUPERUSER
| CREATEDB | NOCREATEDB
| CREATEROLE | NOCREATEROLE
| INHERIT | NOINHERIT
| LOGIN | NOLOGIN
Add REPLICATION privilege for ROLEs This privilege is required to do Streaming Replication, instead of superuser, making it possible to set up a SR slave that doesn't have write permissions on the master. Superuser privileges do NOT override this check, so in order to use the default superuser account for replication it must be explicitly granted the REPLICATION permissions. This is backwards incompatible change, in the interest of higher default security.
2010-12-29 11:05:03 +01:00
| REPLICATION | NOREPLICATION
Row-Level Security Policies (RLS) Building on the updatable security-barrier views work, add the ability to define policies on tables to limit the set of rows which are returned from a query and which are allowed to be added to a table. Expressions defined by the policy for filtering are added to the security barrier quals of the query, while expressions defined to check records being added to a table are added to the with-check options of the query. New top-level commands are CREATE/ALTER/DROP POLICY and are controlled by the table owner. Row Security is able to be enabled and disabled by the owner on a per-table basis using ALTER TABLE .. ENABLE/DISABLE ROW SECURITY. Per discussion, ROW SECURITY is disabled on tables by default and must be enabled for policies on the table to be used. If no policies exist on a table with ROW SECURITY enabled, a default-deny policy is used and no records will be visible. By default, row security is applied at all times except for the table owner and the superuser. A new GUC, row_security, is added which can be set to ON, OFF, or FORCE. When set to FORCE, row security will be applied even for the table owner and superusers. When set to OFF, row security will be disabled when allowed and an error will be thrown if the user does not have rights to bypass row security. Per discussion, pg_dump sets row_security = OFF by default to ensure that exports and backups will have all data in the table or will error if there are insufficient privileges to bypass row security. A new option has been added to pg_dump, --enable-row-security, to ask pg_dump to export with row security enabled. A new role capability, BYPASSRLS, which can only be set by the superuser, is added to allow other users to be able to bypass row security using row_security = OFF. Many thanks to the various individuals who have helped with the design, particularly Robert Haas for his feedback. Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean Rasheed, with additional changes and rework by me. Reviewers have included all of the above, Greg Smith, Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
| BYPASSRLS | NOBYPASSRLS
Use lower-case SGML attribute values for DocBook XML compatibility
2017-10-09 04:00:57 +02:00
| CONNECTION LIMIT <replaceable class="parameter">connlimit</replaceable>
Clarify documentation about PASSWORD in CREATE/ALTER ROLE The documentation of CREATE/ALTER ROLE has been missing two things related to PASSWORD: - The password value provided needs to be quoted, some places of the documentation marked the field with quotes, but not others, which led to confusion. - PASSWORD NULL was not provided consistently, with ENCRYPTED being not compatible with it. Reported-by: Steven Winfield Author: Michael Paquier Reviewed-by: David G. Johnston Discussion: https://postgr.es/m/154282901979.1316.7418475422120496802@wrigleys.postgresql.org
2018-11-23 01:10:24 +01:00
| [ ENCRYPTED ] PASSWORD '<replaceable class="parameter">password</replaceable>' | PASSWORD NULL
Use lower-case SGML attribute values for DocBook XML compatibility
2017-10-09 04:00:57 +02:00
| VALID UNTIL '<replaceable class="parameter">timestamp</replaceable>'
| IN ROLE <replaceable class="parameter">role_name</replaceable> [, ...]
| ROLE <replaceable class="parameter">role_name</replaceable> [, ...]
| ADMIN <replaceable class="parameter">role_name</replaceable> [, ...]
| SYSID <replaceable class="parameter">uid</replaceable>
Basic documentation for ROLEs. The user-manag chapter still needs to be rewritten, but at least the reference pages are reasonably sane.
2005-07-27 01:24:02 +02:00
</synopsis>
</refsynopsisdiv>
Doc: sync CREATE GROUP syntax synopsis with CREATE ROLE. CREATE GROUP is an exact alias for CREATE ROLE, and CREATE USER is almost an exact alias, as can easily be confirmed by checking the code. So the man page syntax descriptions ought to match up. The last few additions of role options seem to have forgotten to update create_group.sgml, though. Fix that, and add a naggy reminder to create_role.sgml in hopes of not forgetting again. Discussion: https://postgr.es/m/158647836143.655.9853963229391401576@wrigleys.postgresql.org
2020-04-10 16:44:09 +02:00
<!--
CAUTION: remember to keep create_user.sgml and create_group.sgml
in sync when changing the above synopsis!
-->
Basic documentation for ROLEs. The user-manag chapter still needs to be rewritten, but at least the reference pages are reasonably sane.
2005-07-27 01:24:02 +02:00
<refsect1>
<title>Description</title>
<para>
<command>CREATE ROLE</command> adds a new role to a
<productname>PostgreSQL</productname> database cluster. A role is
an entity that can own database objects and have database privileges;
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
a role can be considered a <quote>user</quote>, a <quote>group</quote>, or both
Basic documentation for ROLEs. The user-manag chapter still needs to be rewritten, but at least the reference pages are reasonably sane.
2005-07-27 01:24:02 +02:00
depending on how it is used. Refer to
Convert documentation to DocBook XML Since some preparation work had already been done, the only source changes left were changing empty-element tags like <xref linkend="foo"> to <xref linkend="foo"/>, and changing the DOCTYPE. The source files are still named *.sgml, but they are actually XML files now. Renaming could be considered later. In the build system, the intermediate step to convert from SGML to XML is removed. Everything is build straight from the source files again. The OpenSP (or the old SP) package is no longer needed. The documentation toolchain instructions are updated and are much simpler now. Peter Eisentraut, Alexander Lakhin, Jürgen Purtz
2017-11-23 15:39:47 +01:00
<xref linkend="user-manag"/> and <xref
linkend="client-authentication"/> for information about managing
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
users and authentication. You must have <literal>CREATEROLE</literal>
Basic documentation for ROLEs. The user-manag chapter still needs to be rewritten, but at least the reference pages are reasonably sane.
2005-07-27 01:24:02 +02:00
privilege or be a database superuser to use this command.
</para>
<para>
Note that roles are defined at the database cluster
level, and so are valid in all databases in the cluster.
</para>
doc: improve role option documentation Role option management was changed in Postgres 16. This patch improves the docs around these changes, including CREATE ROLE's INHERIT option, inheritance handling, and grant's ability to change role options. Discussion: https://postgr.es/m/Zab9GiV63EENDcWG@momjian.us Co-authored-by: David G. Johnston Backpatch-through: 16
2024-02-01 12:11:53 +01:00
<para>
During role creation it is possible to immediately assign the newly created
role to be a member of an existing role, and also assign existing roles
to be members of the newly created role. The rules for which initial
role membership options are enabled described below in the
<literal>IN ROLE</literal>, <literal>ROLE</literal>, and
<literal>ADMIN</literal> clauses. The <xref linkend="sql-grant"/>
command has fine-grained option control during membership creation,
and the ability to modify these options after the new role is created.
</para>
Basic documentation for ROLEs. The user-manag chapter still needs to be rewritten, but at least the reference pages are reasonably sane.
2005-07-27 01:24:02 +02:00
</refsect1>
<refsect1>
<title>Parameters</title>
<variablelist>
<varlistentry>
<term><replaceable class="parameter">name</replaceable></term>
<listitem>
<para>
The name of the new role.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>SUPERUSER</literal></term>
<term><literal>NOSUPERUSER</literal></term>
<listitem>
<para>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
These clauses determine whether the new role is a <quote>superuser</quote>,
Basic documentation for ROLEs. The user-manag chapter still needs to be rewritten, but at least the reference pages are reasonably sane.
2005-07-27 01:24:02 +02:00
who can override all access restrictions within the database.
Superuser status is dangerous and should be used only when really
needed. You must yourself be a superuser to create a new superuser.
If not specified,
<literal>NOSUPERUSER</literal> is the default.
</para>
</listitem>
</varlistentry>
<varlistentry>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<term><literal>CREATEDB</literal></term>
<term><literal>NOCREATEDB</literal></term>
Basic documentation for ROLEs. The user-manag chapter still needs to be rewritten, but at least the reference pages are reasonably sane.
2005-07-27 01:24:02 +02:00
<listitem>
<para>
These clauses define a role's ability to create databases. If
<literal>CREATEDB</literal> is specified, the role being
defined will be allowed to create new databases. Specifying
<literal>NOCREATEDB</literal> will deny a role the ability to
create databases. If not specified,
<literal>NOCREATEDB</literal> is the default.
Adjust interaction of CREATEROLE with role properties. Previously, a CREATEROLE user without SUPERUSER could not alter REPLICATION users in any way, and could not set the BYPASSRLS attribute. However, they could manipulate the CREATEDB property even if they themselves did not possess it. With this change, a CREATEROLE user without SUPERUSER can set or clear the REPLICATION, BYPASSRLS, or CREATEDB property on a new role or a role that they have rights to manage if and only if that property is set for their own role. This implements the standard idea that you can't give permissions you don't have (but you can give the ones you do have). We might in the future want to provide more powerful ways to constrain what a CREATEROLE user can do - for example, to limit whether CONNECTION LIMIT can be set or the values to which it can be set - but that is left as future work. Patch by me, reviewed by Nathan Bossart, Tushar Ahuja, and Neha Sharma. Discussion: http://postgr.es/m/CA+TgmobX=LHg_J5aT=0pi9gJy=JdtrUVGAu0zhr-i5v5nNbJDg@mail.gmail.com
2023-01-24 16:57:09 +01:00
Only superuser roles or roles with <literal>CREATEDB</literal>
can specify <literal>CREATEDB</literal>.
Basic documentation for ROLEs. The user-manag chapter still needs to be rewritten, but at least the reference pages are reasonably sane.
2005-07-27 01:24:02 +02:00
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>CREATEROLE</literal></term>
<term><literal>NOCREATEROLE</literal></term>
<listitem>
<para>
These clauses determine whether a role will be permitted to
Restrict the privileges of CREATEROLE users. Previously, CREATEROLE users were permitted to make nearly arbitrary changes to roles that they didn't create, with certain exceptions, particularly superuser roles. Instead, allow CREATEROLE users to make such changes to roles for which they possess ADMIN OPTION, and to grant membership only in roles for which they possess ADMIN OPTION. When a CREATEROLE user who is not a superuser creates a role, grant ADMIN OPTION on the newly-created role to the creator, so that they can administer roles they create or for which they have been given privileges. With these changes, CREATEROLE users still have very significant powers that unprivileged users do not receive: they can alter, rename, drop, comment on, change the password for, and change security labels on roles. However, they can now do these things only for roles for which they possess appropriate privileges, rather than all non-superuser roles; moreover, they cannot grant a role such as pg_execute_server_program unless they themselves possess it. Patch by me, reviewed by Mark Dilger. Discussion: https://postgr.es/m/CA+TgmobN59ct+Emmz6ig1Nua2Q-_o=r6DSD98KfU53kctq_kQw@mail.gmail.com
2023-01-10 18:44:30 +01:00
create, alter, drop, comment on, and change the security label for
other roles.
Replace single-quotes with double-quotes in a few SGML attributes. Both are valid SGML, but let's be consistent. Author: Peter Smith Discussion: https://www.postgresql.org/message-id/CAHut%2BPtghjg0SBUTv%3D4Bpcy68d1zD3VAnZ3wX1DQSp39XKD9Sw%40mail.gmail.com
2023-02-27 08:55:39 +01:00
See <xref linkend="role-creation"/> for more details about what
Improve documentation of the CREATEROLE attibute. In user-manag.sgml, document precisely what privileges are conveyed by CREATEROLE. Make particular note of the fact that it allows changing passwords and granting access to high-privilege roles. Also remove the suggestion of using a user with CREATEROLE and CREATEDB instead of a superuser, as there is no real security advantage to this approach. Elsewhere in the documentation, adjust text that suggests that <literal>CREATEROLE</literal> only allows for role creation, and refer to the documentation in user-manag.sgml as appropriate. Patch by me, reviewed by Álvaro Herrera Discussion: http://postgr.es/m/CA+TgmoZBsPL8nPhvYecx7iGo5qpDRqa9k_AcaW1SbOjugAY1Ag@mail.gmail.com
2023-01-03 20:50:40 +01:00
capabilities are conferred by this privilege.
If not specified, <literal>NOCREATEROLE</literal> is the default.
Basic documentation for ROLEs. The user-manag chapter still needs to be rewritten, but at least the reference pages are reasonably sane.
2005-07-27 01:24:02 +02:00
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>INHERIT</literal></term>
<term><literal>NOINHERIT</literal></term>
<listitem>
<para>
doc: improve role option documentation Role option management was changed in Postgres 16. This patch improves the docs around these changes, including CREATE ROLE's INHERIT option, inheritance handling, and grant's ability to change role options. Discussion: https://postgr.es/m/Zab9GiV63EENDcWG@momjian.us Co-authored-by: David G. Johnston Backpatch-through: 16
2024-02-01 12:11:53 +01:00
This affects the membership inheritance status when this
role is added as a member of another role, both in this and
future commands. Specifically, it controls the inheritance
status of memberships added with this command using the
<literal>IN ROLE</literal> clause, and in later commands using
the <literal>ROLE</literal> clause. It is also used as the
default inheritance status when adding this role as a member
using the <literal>GRANT</literal> command. If not specified,
<literal>INHERIT</literal> is the default.
Allow grant-level control of role inheritance behavior. The GRANT statement can now specify WITH INHERIT TRUE or WITH INHERIT FALSE to control whether the member inherits the granted role's permissions. For symmetry, you can now likewise write WITH ADMIN TRUE or WITH ADMIN FALSE to turn ADMIN OPTION on or off. If a GRANT does not specify WITH INHERIT, the behavior based on whether the member role is marked INHERIT or NOINHERIT. This means that if all roles are marked INHERIT or NOINHERIT before any role grants are performed, the behavior is identical to what we had before; otherwise, it's different, because ALTER ROLE [NO]INHERIT now only changes the default behavior of future grants, and has no effect on existing ones. Patch by me. Reviewed and testing by Nathan Bossart and Tushar Ahuja, with design-level comments from various others. Discussion: http://postgr.es/m/CA+Tgmoa5Sf4PiWrfxA=sGzDKg0Ojo3dADw=wAHOhR9dggV=RmQ@mail.gmail.com
2022-08-25 16:06:02 +02:00
</para>
<para>
In <productname>PostgreSQL</productname> versions before 16,
doc: improve role option documentation Role option management was changed in Postgres 16. This patch improves the docs around these changes, including CREATE ROLE's INHERIT option, inheritance handling, and grant's ability to change role options. Discussion: https://postgr.es/m/Zab9GiV63EENDcWG@momjian.us Co-authored-by: David G. Johnston Backpatch-through: 16
2024-02-01 12:11:53 +01:00
inheritance was a role-level attribute that controlled all runtime
membership checks for that role.
Basic documentation for ROLEs. The user-manag chapter still needs to be rewritten, but at least the reference pages are reasonably sane.
2005-07-27 01:24:02 +02:00
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>LOGIN</literal></term>
<term><literal>NOLOGIN</literal></term>
<listitem>
<para>
These clauses determine whether a role is allowed to log in;
that is, whether the role can be given as the initial session
authorization name during client connection. A role having
Update administrator's guide chapters for ROLEs patch.
2005-08-15 01:35:38 +02:00
the <literal>LOGIN</literal> attribute can be thought of as a user.
Basic documentation for ROLEs. The user-manag chapter still needs to be rewritten, but at least the reference pages are reasonably sane.
2005-07-27 01:24:02 +02:00
Roles without this attribute are useful for managing database
privileges, but are not users in the usual sense of the word.
If not specified,
<literal>NOLOGIN</literal> is the default, except when
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<command>CREATE ROLE</command> is invoked through its alternative spelling
Improve <xref> vs. <command> formatting in the documentation SQL commands are generally marked up as <command>, except when a link to a reference page is used using <xref>. But the latter doesn't create monospace markup, so this looks strange especially when a paragraph contains a mix of links and non-links. We considered putting <command> in the <refentrytitle> on the target side, but that creates some formatting side effects elsewhere. Generally, it seems safer to solve this on the link source side. We can't put the <xref> inside the <command>; the DTD doesn't allow this. DocBook 5 would allow the <command> to have the linkend attribute itself, but we are not there yet. So to solve this for now, convert the <xref>s to <link> plus <command>. This gives the correct look and also gives some more flexibility what we can put into the link text (e.g., subcommands or other clauses). In the future, these could then be converted to DocBook 5 style. I haven't converted absolutely all xrefs to SQL command reference pages, only those where we care about the appearance of the link text or where it was otherwise appropriate to make the appearance match a bit better. Also in some cases, the links where repetitive, so in those cases the links where just removed and replaced by a plain <command>. In cases where we just want the link and don't specifically care about the generated link text (typically phrased "for further information see <xref ...>") the xref is kept. Reported-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> Discussion: https://www.postgresql.org/message-id/flat/87o8pco34z.fsf@wibble.ilmari.org
2020-10-03 16:16:51 +02:00
<link linkend="sql-createuser"><command>CREATE USER</command></link>.
Basic documentation for ROLEs. The user-manag chapter still needs to be rewritten, but at least the reference pages are reasonably sane.
2005-07-27 01:24:02 +02:00
</para>
</listitem>
</varlistentry>
Add REPLICATION privilege for ROLEs This privilege is required to do Streaming Replication, instead of superuser, making it possible to set up a SR slave that doesn't have write permissions on the master. Superuser privileges do NOT override this check, so in order to use the default superuser account for replication it must be explicitly granted the REPLICATION permissions. This is backwards incompatible change, in the interest of higher default security.
2010-12-29 11:05:03 +01:00
<varlistentry>
<term><literal>REPLICATION</literal></term>
<term><literal>NOREPLICATION</literal></term>
<listitem>
<para>
doc: Update description of rolreplication column Since PostgreSQL 9.6, rolreplication no longer determines whether a role can run pg_start_backup() and pg_stop_backup(), so remove that. Add that this attribute determines whether a role can create and drop replication slots. Reported-by: Fujii Masao <masao.fujii@gmail.com>
2017-08-11 22:14:55 +02:00
These clauses determine whether a role is a replication role. A role
must have this attribute (or be a superuser) in order to be able to
connect to the server in replication mode (physical or logical
replication) and in order to be able to create or drop replication
slots.
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
A role having the <literal>REPLICATION</literal> attribute is a very
Add REPLICATION privilege for ROLEs This privilege is required to do Streaming Replication, instead of superuser, making it possible to set up a SR slave that doesn't have write permissions on the master. Superuser privileges do NOT override this check, so in order to use the default superuser account for replication it must be explicitly granted the REPLICATION permissions. This is backwards incompatible change, in the interest of higher default security.
2010-12-29 11:05:03 +01:00
highly privileged role, and should only be used on roles actually
Remove tabs in SGML
2010-12-30 21:15:55 +01:00
used for replication. If not specified,
Make superuser imply replication privilege. The idea of a privilege that superuser doesn't have doesn't make much sense, as a superuser can do whatever he wants through other means, anyway. So instead of granting replication privilege to superusers in CREATE USER time by default, allow replication connection from superusers whether or not they have the replication privilege. Patch by Noah Misch, per discussion on bug report #6264
2012-01-14 17:22:16 +01:00
<literal>NOREPLICATION</literal> is the default.
Adjust interaction of CREATEROLE with role properties. Previously, a CREATEROLE user without SUPERUSER could not alter REPLICATION users in any way, and could not set the BYPASSRLS attribute. However, they could manipulate the CREATEDB property even if they themselves did not possess it. With this change, a CREATEROLE user without SUPERUSER can set or clear the REPLICATION, BYPASSRLS, or CREATEDB property on a new role or a role that they have rights to manage if and only if that property is set for their own role. This implements the standard idea that you can't give permissions you don't have (but you can give the ones you do have). We might in the future want to provide more powerful ways to constrain what a CREATEROLE user can do - for example, to limit whether CONNECTION LIMIT can be set or the values to which it can be set - but that is left as future work. Patch by me, reviewed by Nathan Bossart, Tushar Ahuja, and Neha Sharma. Discussion: http://postgr.es/m/CA+TgmobX=LHg_J5aT=0pi9gJy=JdtrUVGAu0zhr-i5v5nNbJDg@mail.gmail.com
2023-01-24 16:57:09 +01:00
Only superuser roles or roles with <literal>REPLICATION</literal>
can specify <literal>REPLICATION</literal>.
Add REPLICATION privilege for ROLEs This privilege is required to do Streaming Replication, instead of superuser, making it possible to set up a SR slave that doesn't have write permissions on the master. Superuser privileges do NOT override this check, so in order to use the default superuser account for replication it must be explicitly granted the REPLICATION permissions. This is backwards incompatible change, in the interest of higher default security.
2010-12-29 11:05:03 +01:00
</para>
</listitem>
</varlistentry>
Row-Level Security Policies (RLS) Building on the updatable security-barrier views work, add the ability to define policies on tables to limit the set of rows which are returned from a query and which are allowed to be added to a table. Expressions defined by the policy for filtering are added to the security barrier quals of the query, while expressions defined to check records being added to a table are added to the with-check options of the query. New top-level commands are CREATE/ALTER/DROP POLICY and are controlled by the table owner. Row Security is able to be enabled and disabled by the owner on a per-table basis using ALTER TABLE .. ENABLE/DISABLE ROW SECURITY. Per discussion, ROW SECURITY is disabled on tables by default and must be enabled for policies on the table to be used. If no policies exist on a table with ROW SECURITY enabled, a default-deny policy is used and no records will be visible. By default, row security is applied at all times except for the table owner and the superuser. A new GUC, row_security, is added which can be set to ON, OFF, or FORCE. When set to FORCE, row security will be applied even for the table owner and superusers. When set to OFF, row security will be disabled when allowed and an error will be thrown if the user does not have rights to bypass row security. Per discussion, pg_dump sets row_security = OFF by default to ensure that exports and backups will have all data in the table or will error if there are insufficient privileges to bypass row security. A new option has been added to pg_dump, --enable-row-security, to ask pg_dump to export with row security enabled. A new role capability, BYPASSRLS, which can only be set by the superuser, is added to allow other users to be able to bypass row security using row_security = OFF. Many thanks to the various individuals who have helped with the design, particularly Robert Haas for his feedback. Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean Rasheed, with additional changes and rework by me. Reviewers have included all of the above, Greg Smith, Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
<varlistentry>
<term><literal>BYPASSRLS</literal></term>
<term><literal>NOBYPASSRLS</literal></term>
<listitem>
<para>
Make BYPASSRLS behave like superuser RLS bypass. Specifically, make its effect independent from the row_security GUC, and make it affect permission checks pertinent to views the BYPASSRLS role owns. The row_security GUC thereby ceases to change successful-query behavior; it can only make a query fail with an error. Back-patch to 9.5, where BYPASSRLS was introduced.
2015-10-04 02:19:57 +02:00
These clauses determine whether a role bypasses every row-level
security (RLS) policy. <literal>NOBYPASSRLS</literal> is the default.
Adjust interaction of CREATEROLE with role properties. Previously, a CREATEROLE user without SUPERUSER could not alter REPLICATION users in any way, and could not set the BYPASSRLS attribute. However, they could manipulate the CREATEDB property even if they themselves did not possess it. With this change, a CREATEROLE user without SUPERUSER can set or clear the REPLICATION, BYPASSRLS, or CREATEDB property on a new role or a role that they have rights to manage if and only if that property is set for their own role. This implements the standard idea that you can't give permissions you don't have (but you can give the ones you do have). We might in the future want to provide more powerful ways to constrain what a CREATEROLE user can do - for example, to limit whether CONNECTION LIMIT can be set or the values to which it can be set - but that is left as future work. Patch by me, reviewed by Nathan Bossart, Tushar Ahuja, and Neha Sharma. Discussion: http://postgr.es/m/CA+TgmobX=LHg_J5aT=0pi9gJy=JdtrUVGAu0zhr-i5v5nNbJDg@mail.gmail.com
2023-01-24 16:57:09 +01:00
Only superuser roles or roles with <literal>BYPASSRLS</literal>
can specify <literal>BYPASSRLS</literal>.
Allow users with BYPASSRLS to alter their own passwords. The intention in commit 491c029db was to require superuserness to change the BYPASSRLS property, but the actual effect of the coding in AlterRole() was to require superuserness to change anything at all about a BYPASSRLS role. Other properties of a BYPASSRLS role should be changeable under the same rules as for a normal role, though. Fix that, and also take care of some documentation omissions related to BYPASSRLS and REPLICATION role properties. Tom Lane and Stephen Frost, per bug report from Wolfgang Walther. Back-patch to all supported branches. Discussion: https://postgr.es/m/a5548a9f-89ee-3167-129d-162b5985fcf8@technowledgy.de
2020-11-03 21:41:32 +01:00
</para>
<para>
Row-Level Security Policies (RLS) Building on the updatable security-barrier views work, add the ability to define policies on tables to limit the set of rows which are returned from a query and which are allowed to be added to a table. Expressions defined by the policy for filtering are added to the security barrier quals of the query, while expressions defined to check records being added to a table are added to the with-check options of the query. New top-level commands are CREATE/ALTER/DROP POLICY and are controlled by the table owner. Row Security is able to be enabled and disabled by the owner on a per-table basis using ALTER TABLE .. ENABLE/DISABLE ROW SECURITY. Per discussion, ROW SECURITY is disabled on tables by default and must be enabled for policies on the table to be used. If no policies exist on a table with ROW SECURITY enabled, a default-deny policy is used and no records will be visible. By default, row security is applied at all times except for the table owner and the superuser. A new GUC, row_security, is added which can be set to ON, OFF, or FORCE. When set to FORCE, row security will be applied even for the table owner and superusers. When set to OFF, row security will be disabled when allowed and an error will be thrown if the user does not have rights to bypass row security. Per discussion, pg_dump sets row_security = OFF by default to ensure that exports and backups will have all data in the table or will error if there are insufficient privileges to bypass row security. A new option has been added to pg_dump, --enable-row-security, to ask pg_dump to export with row security enabled. A new role capability, BYPASSRLS, which can only be set by the superuser, is added to allow other users to be able to bypass row security using row_security = OFF. Many thanks to the various individuals who have helped with the design, particularly Robert Haas for his feedback. Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean Rasheed, with additional changes and rework by me. Reviewers have included all of the above, Greg Smith, Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
Note that pg_dump will set <literal>row_security</literal> to
<literal>OFF</literal> by default, to ensure all contents of a table are
dumped out. If the user running pg_dump does not have appropriate
Allow users with BYPASSRLS to alter their own passwords. The intention in commit 491c029db was to require superuserness to change the BYPASSRLS property, but the actual effect of the coding in AlterRole() was to require superuserness to change anything at all about a BYPASSRLS role. Other properties of a BYPASSRLS role should be changeable under the same rules as for a normal role, though. Fix that, and also take care of some documentation omissions related to BYPASSRLS and REPLICATION role properties. Tom Lane and Stephen Frost, per bug report from Wolfgang Walther. Back-patch to all supported branches. Discussion: https://postgr.es/m/a5548a9f-89ee-3167-129d-162b5985fcf8@technowledgy.de
2020-11-03 21:41:32 +01:00
permissions, an error will be returned. However, superusers and the
owner of the table being dumped always bypass RLS.
Row-Level Security Policies (RLS) Building on the updatable security-barrier views work, add the ability to define policies on tables to limit the set of rows which are returned from a query and which are allowed to be added to a table. Expressions defined by the policy for filtering are added to the security barrier quals of the query, while expressions defined to check records being added to a table are added to the with-check options of the query. New top-level commands are CREATE/ALTER/DROP POLICY and are controlled by the table owner. Row Security is able to be enabled and disabled by the owner on a per-table basis using ALTER TABLE .. ENABLE/DISABLE ROW SECURITY. Per discussion, ROW SECURITY is disabled on tables by default and must be enabled for policies on the table to be used. If no policies exist on a table with ROW SECURITY enabled, a default-deny policy is used and no records will be visible. By default, row security is applied at all times except for the table owner and the superuser. A new GUC, row_security, is added which can be set to ON, OFF, or FORCE. When set to FORCE, row security will be applied even for the table owner and superusers. When set to OFF, row security will be disabled when allowed and an error will be thrown if the user does not have rights to bypass row security. Per discussion, pg_dump sets row_security = OFF by default to ensure that exports and backups will have all data in the table or will error if there are insufficient privileges to bypass row security. A new option has been added to pg_dump, --enable-row-security, to ask pg_dump to export with row security enabled. A new role capability, BYPASSRLS, which can only be set by the superuser, is added to allow other users to be able to bypass row security using row_security = OFF. Many thanks to the various individuals who have helped with the design, particularly Robert Haas for his feedback. Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean Rasheed, with additional changes and rework by me. Reviewers have included all of the above, Greg Smith, Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
</para>
</listitem>
</varlistentry>
Add per-user and per-database connection limit options. This patch also includes preliminary update of pg_dumpall for roles. Petr Jelinek, with review by Bruce Momjian and Tom Lane.
2005-07-31 19:19:22 +02:00
<varlistentry>
<term><literal>CONNECTION LIMIT</literal> <replaceable class="parameter">connlimit</replaceable></term>
<listitem>
<para>
If role can log in, this specifies how many concurrent connections
Don't count background workers against a user's connection limit. Doing so doesn't seem to be within the purpose of the per user connection limits, and has particularly unfortunate effects in conjunction with parallel queries. Backpatch to 9.6 where parallel queries were introduced. David Rowley, reviewed by Robert Haas and Albe Laurenz.
2017-02-01 23:52:35 +01:00
the role can make. -1 (the default) means no limit. Note that only
normal connections are counted towards this limit. Neither prepared
transactions nor background worker connections are counted towards
this limit.
Add per-user and per-database connection limit options. This patch also includes preliminary update of pg_dumpall for roles. Petr Jelinek, with review by Bruce Momjian and Tom Lane.
2005-07-31 19:19:22 +02:00
</para>
</listitem>
</varlistentry>
Basic documentation for ROLEs. The user-manag chapter still needs to be rewritten, but at least the reference pages are reasonably sane.
2005-07-27 01:24:02 +02:00
<varlistentry>
Clarify documentation about PASSWORD in CREATE/ALTER ROLE The documentation of CREATE/ALTER ROLE has been missing two things related to PASSWORD: - The password value provided needs to be quoted, some places of the documentation marked the field with quotes, but not others, which led to confusion. - PASSWORD NULL was not provided consistently, with ENCRYPTED being not compatible with it. Reported-by: Steven Winfield Author: Michael Paquier Reviewed-by: David G. Johnston Discussion: https://postgr.es/m/154282901979.1316.7418475422120496802@wrigleys.postgresql.org
2018-11-23 01:10:24 +01:00
<term>[ <literal>ENCRYPTED</literal> ] <literal>PASSWORD</literal> '<replaceable class="parameter">password</replaceable>'</term>
<term><literal>PASSWORD NULL</literal></term>
Basic documentation for ROLEs. The user-manag chapter still needs to be rewritten, but at least the reference pages are reasonably sane.
2005-07-27 01:24:02 +02:00
<listitem>
<para>
Sets the role's password. (A password is only of use for
Allow CREATE/ALTER ROLE PASSWORD NULL to allow restoring the default state of having no password.
2005-12-23 17:46:39 +01:00
roles having the <literal>LOGIN</literal> attribute, but you
can nonetheless define one for roles without it.) If you do
not plan to use password authentication you can omit this
option. If no password is specified, the password will be set
to null and password authentication will always fail for that
user. A null password can optionally be written explicitly as
<literal>PASSWORD NULL</literal>.
Basic documentation for ROLEs. The user-manag chapter still needs to be rewritten, but at least the reference pages are reasonably sane.
2005-07-27 01:24:02 +02:00
</para>
Don't allow logging in with empty password. Some authentication methods allowed it, others did not. In the client-side, libpq does not even try to authenticate with an empty password, which makes using empty passwords hazardous: an administrator might think that an account with an empty password cannot be used to log in, because psql doesn't allow it, and not realize that a different client would in fact allow it. To clear that confusion and to be be consistent, disallow empty passwords in all authentication methods. All the authentication methods that used plaintext authentication over the wire, except for BSD authentication, already checked that the password received from the user was not empty. To avoid forgetting it in the future again, move the check to the recv_password_packet function. That only forbids using an empty password with plaintext authentication, however. MD5 and SCRAM need a different fix: * In stable branches, check that the MD5 hash stored for the user does not not correspond to an empty string. This adds some overhead to MD5 authentication, because the server needs to compute an extra MD5 hash, but it is not noticeable in practice. * In HEAD, modify CREATE and ALTER ROLE to clear the password if an empty string, or a password hash that corresponds to an empty string, is specified. The user-visible behavior is the same as in the stable branches, the user cannot log in, but it seems better to stop the empty password from entering the system in the first place. Secondly, it is fairly expensive to check that a SCRAM hash doesn't correspond to an empty string, because computing a SCRAM hash is much more expensive than an MD5 hash by design, so better avoid doing that on every authentication. We could clear the password on CREATE/ALTER ROLE also in stable branches, but we would still need to check at authentication time, because even if we prevent empty passwords from being stored in pg_authid, there might be existing ones there already. Reported by Jeroen van der Ham, Ben de Graaff and Jelte Fennema. Security: CVE-2017-7546
2017-08-07 16:03:42 +02:00
<note>
<para>
Specifying an empty string will also set the password to null,
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
but that was not the case before <productname>PostgreSQL</productname>
Don't allow logging in with empty password. Some authentication methods allowed it, others did not. In the client-side, libpq does not even try to authenticate with an empty password, which makes using empty passwords hazardous: an administrator might think that an account with an empty password cannot be used to log in, because psql doesn't allow it, and not realize that a different client would in fact allow it. To clear that confusion and to be be consistent, disallow empty passwords in all authentication methods. All the authentication methods that used plaintext authentication over the wire, except for BSD authentication, already checked that the password received from the user was not empty. To avoid forgetting it in the future again, move the check to the recv_password_packet function. That only forbids using an empty password with plaintext authentication, however. MD5 and SCRAM need a different fix: * In stable branches, check that the MD5 hash stored for the user does not not correspond to an empty string. This adds some overhead to MD5 authentication, because the server needs to compute an extra MD5 hash, but it is not noticeable in practice. * In HEAD, modify CREATE and ALTER ROLE to clear the password if an empty string, or a password hash that corresponds to an empty string, is specified. The user-visible behavior is the same as in the stable branches, the user cannot log in, but it seems better to stop the empty password from entering the system in the first place. Secondly, it is fairly expensive to check that a SCRAM hash doesn't correspond to an empty string, because computing a SCRAM hash is much more expensive than an MD5 hash by design, so better avoid doing that on every authentication. We could clear the password on CREATE/ALTER ROLE also in stable branches, but we would still need to check at authentication time, because even if we prevent empty passwords from being stored in pg_authid, there might be existing ones there already. Reported by Jeroen van der Ham, Ben de Graaff and Jelte Fennema. Security: CVE-2017-7546
2017-08-07 16:03:42 +02:00
version 10. In earlier versions, an empty string could be used,
or not, depending on the authentication method and the exact
version, and libpq would refuse to use it in any case.
To avoid the ambiguity, specifying an empty string should be
avoided.
</para>
</note>
Basic documentation for ROLEs. The user-manag chapter still needs to be rewritten, but at least the reference pages are reasonably sane.
2005-07-27 01:24:02 +02:00
<para>
Remove support for password_encryption='off' / 'plain'. Storing passwords in plaintext hasn't been a good idea for a very long time, if ever. Now seems like a good time to finally forbid it, since we're messing with this in PostgreSQL 10 anyway. Remove the CREATE/ALTER USER UNENCRYPTED PASSSWORD 'foo' syntax, since storing passwords unencrypted is no longer supported. ENCRYPTED PASSWORD 'foo' is still accepted, but ENCRYPTED is now just a noise-word, it does the same as just PASSWORD 'foo'. Likewise, remove the --unencrypted option from createuser, but accept --encrypted as a no-op for backward compatibility. AFAICS, --encrypted was a no-op even before this patch, because createuser encrypted the password before sending it to the server even if --encrypted was not specified. It added the ENCRYPTED keyword to the SQL command, but since the password was already in encrypted form, it didn't make any difference. The documentation was not clear on whether that was intended or not, but it's moot now. Also, while password_encryption='on' is still accepted as an alias for 'md5', it is now marked as hidden, so that it is not listed as an accepted value in error hints, for example. That's not directly related to removing 'plain', but it seems better this way. Reviewed by Michael Paquier Discussion: https://www.postgresql.org/message-id/16e9b768-fd78-0b12-cfc1-7b6b7f238fde@iki.fi
2017-05-08 10:26:07 +02:00
The password is always stored encrypted in the system catalogs. The
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<literal>ENCRYPTED</literal> keyword has no effect, but is accepted for
Remove support for password_encryption='off' / 'plain'. Storing passwords in plaintext hasn't been a good idea for a very long time, if ever. Now seems like a good time to finally forbid it, since we're messing with this in PostgreSQL 10 anyway. Remove the CREATE/ALTER USER UNENCRYPTED PASSSWORD 'foo' syntax, since storing passwords unencrypted is no longer supported. ENCRYPTED PASSWORD 'foo' is still accepted, but ENCRYPTED is now just a noise-word, it does the same as just PASSWORD 'foo'. Likewise, remove the --unencrypted option from createuser, but accept --encrypted as a no-op for backward compatibility. AFAICS, --encrypted was a no-op even before this patch, because createuser encrypted the password before sending it to the server even if --encrypted was not specified. It added the ENCRYPTED keyword to the SQL command, but since the password was already in encrypted form, it didn't make any difference. The documentation was not clear on whether that was intended or not, but it's moot now. Also, while password_encryption='on' is still accepted as an alias for 'md5', it is now marked as hidden, so that it is not listed as an accepted value in error hints, for example. That's not directly related to removing 'plain', but it seems better this way. Reviewed by Michael Paquier Discussion: https://www.postgresql.org/message-id/16e9b768-fd78-0b12-cfc1-7b6b7f238fde@iki.fi
2017-05-08 10:26:07 +02:00
backwards compatibility. The method of encryption is determined
Convert documentation to DocBook XML Since some preparation work had already been done, the only source changes left were changing empty-element tags like <xref linkend="foo"> to <xref linkend="foo"/>, and changing the DOCTYPE. The source files are still named *.sgml, but they are actually XML files now. Renaming could be considered later. In the build system, the intermediate step to convert from SGML to XML is removed. Everything is build straight from the source files again. The OpenSP (or the old SP) package is no longer needed. The documentation toolchain instructions are updated and are much simpler now. Peter Eisentraut, Alexander Lakhin, Jürgen Purtz
2017-11-23 15:39:47 +01:00
by the configuration parameter <xref linkend="guc-password-encryption"/>.
Remove support for password_encryption='off' / 'plain'. Storing passwords in plaintext hasn't been a good idea for a very long time, if ever. Now seems like a good time to finally forbid it, since we're messing with this in PostgreSQL 10 anyway. Remove the CREATE/ALTER USER UNENCRYPTED PASSSWORD 'foo' syntax, since storing passwords unencrypted is no longer supported. ENCRYPTED PASSWORD 'foo' is still accepted, but ENCRYPTED is now just a noise-word, it does the same as just PASSWORD 'foo'. Likewise, remove the --unencrypted option from createuser, but accept --encrypted as a no-op for backward compatibility. AFAICS, --encrypted was a no-op even before this patch, because createuser encrypted the password before sending it to the server even if --encrypted was not specified. It added the ENCRYPTED keyword to the SQL command, but since the password was already in encrypted form, it didn't make any difference. The documentation was not clear on whether that was intended or not, but it's moot now. Also, while password_encryption='on' is still accepted as an alias for 'md5', it is now marked as hidden, so that it is not listed as an accepted value in error hints, for example. That's not directly related to removing 'plain', but it seems better this way. Reviewed by Michael Paquier Discussion: https://www.postgresql.org/message-id/16e9b768-fd78-0b12-cfc1-7b6b7f238fde@iki.fi
2017-05-08 10:26:07 +02:00
If the presented password string is already in MD5-encrypted or
SCRAM-encrypted format, then it is stored as-is regardless of
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<varname>password_encryption</varname> (since the system cannot decrypt
Remove support for password_encryption='off' / 'plain'. Storing passwords in plaintext hasn't been a good idea for a very long time, if ever. Now seems like a good time to finally forbid it, since we're messing with this in PostgreSQL 10 anyway. Remove the CREATE/ALTER USER UNENCRYPTED PASSSWORD 'foo' syntax, since storing passwords unencrypted is no longer supported. ENCRYPTED PASSWORD 'foo' is still accepted, but ENCRYPTED is now just a noise-word, it does the same as just PASSWORD 'foo'. Likewise, remove the --unencrypted option from createuser, but accept --encrypted as a no-op for backward compatibility. AFAICS, --encrypted was a no-op even before this patch, because createuser encrypted the password before sending it to the server even if --encrypted was not specified. It added the ENCRYPTED keyword to the SQL command, but since the password was already in encrypted form, it didn't make any difference. The documentation was not clear on whether that was intended or not, but it's moot now. Also, while password_encryption='on' is still accepted as an alias for 'md5', it is now marked as hidden, so that it is not listed as an accepted value in error hints, for example. That's not directly related to removing 'plain', but it seems better this way. Reviewed by Michael Paquier Discussion: https://www.postgresql.org/message-id/16e9b768-fd78-0b12-cfc1-7b6b7f238fde@iki.fi
2017-05-08 10:26:07 +02:00
the specified encrypted password string, to encrypt it in a
different format). This allows reloading of encrypted passwords
Support SCRAM-SHA-256 authentication (RFC 5802 and 7677). This introduces a new generic SASL authentication method, similar to the GSS and SSPI methods. The server first tells the client which SASL authentication mechanism to use, and then the mechanism-specific SASL messages are exchanged in AuthenticationSASLcontinue and PasswordMessage messages. Only SCRAM-SHA-256 is supported at the moment, but this allows adding more SASL mechanisms in the future, without changing the overall protocol. Support for channel binding, aka SCRAM-SHA-256-PLUS is left for later. The SASLPrep algorithm, for pre-processing the password, is not yet implemented. That could cause trouble, if you use a password with non-ASCII characters, and a client library that does implement SASLprep. That will hopefully be added later. Authorization identities, as specified in the SCRAM-SHA-256 specification, are ignored. SET SESSION AUTHORIZATION provides more or less the same functionality, anyway. If a user doesn't exist, perform a "mock" authentication, by constructing an authentic-looking challenge on the fly. The challenge is derived from a new system-wide random value, "mock authentication nonce", which is created at initdb, and stored in the control file. We go through these motions, in order to not give away the information on whether the user exists, to unauthenticated users. Bumps PG_CONTROL_VERSION, because of the new field in control file. Patch by Michael Paquier and Heikki Linnakangas, reviewed at different stages by Robert Haas, Stephen Frost, David Steele, Aleksander Alekseev, and many others. Discussion: https://www.postgresql.org/message-id/CAB7nPqRbR3GmFYdedCAhzukfKrgBLTLtMvENOmPrVWREsZkF8g%40mail.gmail.com Discussion: https://www.postgresql.org/message-id/CAB7nPqSMXU35g%3DW9X74HVeQp0uvgJxvYOuA4A-A3M%2B0wfEBv-w%40mail.gmail.com Discussion: https://www.postgresql.org/message-id/55192AFE.6080106@iki.fi
2017-03-07 13:25:40 +01:00
during dump/restore.
</para>
Basic documentation for ROLEs. The user-manag chapter still needs to be rewritten, but at least the reference pages are reasonably sane.
2005-07-27 01:24:02 +02:00
</listitem>
</varlistentry>
<varlistentry>
<term><literal>VALID UNTIL</literal> '<replaceable class="parameter">timestamp</replaceable>'</term>
<listitem>
<para>
The <literal>VALID UNTIL</literal> clause sets a date and
time after which the role's password is no longer valid. If
this clause is omitted the password will be valid for all time.
</para>
</listitem>
</varlistentry>
<varlistentry>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<term><literal>IN ROLE</literal> <replaceable class="parameter">role_name</replaceable></term>
Basic documentation for ROLEs. The user-manag chapter still needs to be rewritten, but at least the reference pages are reasonably sane.
2005-07-27 01:24:02 +02:00
<listitem>
<para>
doc: improve description of adding roles as members Discussion: https://postgr.es/m/ZFvVZvQDliIWmOwg@momjian.us
2023-05-19 04:22:17 +02:00
The <literal>IN ROLE</literal> clause causes the new role to
be automatically added as a member of the specified existing
doc: improve role option documentation Role option management was changed in Postgres 16. This patch improves the docs around these changes, including CREATE ROLE's INHERIT option, inheritance handling, and grant's ability to change role options. Discussion: https://postgr.es/m/Zab9GiV63EENDcWG@momjian.us Co-authored-by: David G. Johnston Backpatch-through: 16
2024-02-01 12:11:53 +01:00
roles. The new membership will have the <literal>SET</literal>
option enabled and the <literal>ADMIN</literal> option disabled.
The <literal>INHERIT</literal> option will be enabled unless the
<literal>NOINHERIT</literal> option is specified.
Basic documentation for ROLEs. The user-manag chapter still needs to be rewritten, but at least the reference pages are reasonably sane.
2005-07-27 01:24:02 +02:00
</para>
</listitem>
</varlistentry>
<varlistentry>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<term><literal>ROLE</literal> <replaceable class="parameter">role_name</replaceable></term>
Basic documentation for ROLEs. The user-manag chapter still needs to be rewritten, but at least the reference pages are reasonably sane.
2005-07-27 01:24:02 +02:00
<listitem>
<para>
doc: improve description of adding roles as members Discussion: https://postgr.es/m/ZFvVZvQDliIWmOwg@momjian.us
2023-05-19 04:22:17 +02:00
The <literal>ROLE</literal> clause causes one or more specified
doc: improve role option documentation Role option management was changed in Postgres 16. This patch improves the docs around these changes, including CREATE ROLE's INHERIT option, inheritance handling, and grant's ability to change role options. Discussion: https://postgr.es/m/Zab9GiV63EENDcWG@momjian.us Co-authored-by: David G. Johnston Backpatch-through: 16
2024-02-01 12:11:53 +01:00
existing roles to be automatically added as members, with the
<literal>SET</literal> option enabled. This in effect makes the
new role a <quote>group</quote>. Roles named in this clause
doc: fix CREATE ROLE typo This wording typo was added in PG 16. Reported-by: s.bailey@chorusintel.com Discussion: https://postgr.es/m/171150077554.7105.801523271545956671@wrigleys.postgresql.org Backpatch-through: 16
2024-03-27 22:58:11 +01:00
with the role-level <literal>INHERIT</literal> attribute will have
doc: improve role option documentation Role option management was changed in Postgres 16. This patch improves the docs around these changes, including CREATE ROLE's INHERIT option, inheritance handling, and grant's ability to change role options. Discussion: https://postgr.es/m/Zab9GiV63EENDcWG@momjian.us Co-authored-by: David G. Johnston Backpatch-through: 16
2024-02-01 12:11:53 +01:00
the <literal>INHERIT</literal> option enabled in the new membership.
New memberships will have the <literal>ADMIN</literal> option disabled.
Basic documentation for ROLEs. The user-manag chapter still needs to be rewritten, but at least the reference pages are reasonably sane.
2005-07-27 01:24:02 +02:00
</para>
</listitem>
</varlistentry>
<varlistentry>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<term><literal>ADMIN</literal> <replaceable class="parameter">role_name</replaceable></term>
Basic documentation for ROLEs. The user-manag chapter still needs to be rewritten, but at least the reference pages are reasonably sane.
2005-07-27 01:24:02 +02:00
<listitem>
<para>
doc: improve role option documentation Role option management was changed in Postgres 16. This patch improves the docs around these changes, including CREATE ROLE's INHERIT option, inheritance handling, and grant's ability to change role options. Discussion: https://postgr.es/m/Zab9GiV63EENDcWG@momjian.us Co-authored-by: David G. Johnston Backpatch-through: 16
2024-02-01 12:11:53 +01:00
The <literal>ADMIN</literal> clause has the same effect as
<literal>ROLE</literal>, but the named roles are added as members
of the new role with <literal>ADMIN</literal> enabled, giving
them the right to grant membership in the new role to others.
Basic documentation for ROLEs. The user-manag chapter still needs to be rewritten, but at least the reference pages are reasonably sane.
2005-07-27 01:24:02 +02:00
</para>
</listitem>
</varlistentry>
<varlistentry>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<term><literal>SYSID</literal> <replaceable class="parameter">uid</replaceable></term>
Basic documentation for ROLEs. The user-manag chapter still needs to be rewritten, but at least the reference pages are reasonably sane.
2005-07-27 01:24:02 +02:00
<listitem>
<para>
The <literal>SYSID</literal> clause is ignored, but is accepted
for backwards compatibility.
</para>
</listitem>
</varlistentry>
</variablelist>
Remove useless whitespace at end of lines
2010-11-23 21:27:50 +01:00
</refsect1>
Basic documentation for ROLEs. The user-manag chapter still needs to be rewritten, but at least the reference pages are reasonably sane.
2005-07-27 01:24:02 +02:00
<refsect1>
<title>Notes</title>
<para>
Improve <xref> vs. <command> formatting in the documentation SQL commands are generally marked up as <command>, except when a link to a reference page is used using <xref>. But the latter doesn't create monospace markup, so this looks strange especially when a paragraph contains a mix of links and non-links. We considered putting <command> in the <refentrytitle> on the target side, but that creates some formatting side effects elsewhere. Generally, it seems safer to solve this on the link source side. We can't put the <xref> inside the <command>; the DTD doesn't allow this. DocBook 5 would allow the <command> to have the linkend attribute itself, but we are not there yet. So to solve this for now, convert the <xref>s to <link> plus <command>. This gives the correct look and also gives some more flexibility what we can put into the link text (e.g., subcommands or other clauses). In the future, these could then be converted to DocBook 5 style. I haven't converted absolutely all xrefs to SQL command reference pages, only those where we care about the appearance of the link text or where it was otherwise appropriate to make the appearance match a bit better. Also in some cases, the links where repetitive, so in those cases the links where just removed and replaced by a plain <command>. In cases where we just want the link and don't specifically care about the generated link text (typically phrased "for further information see <xref ...>") the xref is kept. Reported-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> Discussion: https://www.postgresql.org/message-id/flat/87o8pco34z.fsf@wibble.ilmari.org
2020-10-03 16:16:51 +02:00
Use <link linkend="sql-alterrole"><command>ALTER ROLE</command></link> to
change the attributes of a role, and <link linkend="sql-droprole"><command>DROP ROLE</command></link>
Remove unnecessary xref endterm attributes and title ids The endterm attribute is mainly useful when the toolchain does not support automatic link target text generation for a particular situation. In the past, this was required by the man page tools for all reference page links, but that is no longer the case, and it now actually gets in the way of proper automatic link text generation. The only remaining use cases are currently xrefs to refsects.
2010-04-03 09:23:02 +02:00
to remove a role. All the attributes
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
specified by <command>CREATE ROLE</command> can be modified by later
<command>ALTER ROLE</command> commands.
Basic documentation for ROLEs. The user-manag chapter still needs to be rewritten, but at least the reference pages are reasonably sane.
2005-07-27 01:24:02 +02:00
</para>
<para>
The preferred way to add and remove members of roles that are being
used as groups is to use
Improve <xref> vs. <command> formatting in the documentation SQL commands are generally marked up as <command>, except when a link to a reference page is used using <xref>. But the latter doesn't create monospace markup, so this looks strange especially when a paragraph contains a mix of links and non-links. We considered putting <command> in the <refentrytitle> on the target side, but that creates some formatting side effects elsewhere. Generally, it seems safer to solve this on the link source side. We can't put the <xref> inside the <command>; the DTD doesn't allow this. DocBook 5 would allow the <command> to have the linkend attribute itself, but we are not there yet. So to solve this for now, convert the <xref>s to <link> plus <command>. This gives the correct look and also gives some more flexibility what we can put into the link text (e.g., subcommands or other clauses). In the future, these could then be converted to DocBook 5 style. I haven't converted absolutely all xrefs to SQL command reference pages, only those where we care about the appearance of the link text or where it was otherwise appropriate to make the appearance match a bit better. Also in some cases, the links where repetitive, so in those cases the links where just removed and replaced by a plain <command>. In cases where we just want the link and don't specifically care about the generated link text (typically phrased "for further information see <xref ...>") the xref is kept. Reported-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> Discussion: https://www.postgresql.org/message-id/flat/87o8pco34z.fsf@wibble.ilmari.org
2020-10-03 16:16:51 +02:00
<link linkend="sql-grant"><command>GRANT</command></link> and
<link linkend="sql-revoke"><command>REVOKE</command></link>.
Basic documentation for ROLEs. The user-manag chapter still needs to be rewritten, but at least the reference pages are reasonably sane.
2005-07-27 01:24:02 +02:00
</para>
<para>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
The <literal>VALID UNTIL</literal> clause defines an expiration time for a
Doc: get rid of <foreignphrase> tags. We italicized some, but not all, instances of "per se", "pro forma", and "ad hoc". These phrases are widespread in formal registers of English, so it"s debatable whether they even qualify as foreign. We could instead try to be more consistent in the use of <foreignphrase>, but that"s difficult to enforce, so let"s just remove the tags for those words. The one case that seems to deserve the tag is "voilà". Instead of keeping just one instance of the tag, change that to a more standard phrase. John Naylor Discussion: https://postgr.es/m/CAFBsxsHtWs_NsccAVgQ=tTUKkXHpHdkjZXtp_Cd9dGWyBDxfbQ@mail.gmail.com
2021-03-10 18:38:43 +01:00
password only, not for the role per se. In
Basic documentation for ROLEs. The user-manag chapter still needs to be rewritten, but at least the reference pages are reasonably sane.
2005-07-27 01:24:02 +02:00
particular, the expiration time is not enforced when logging in using
a non-password-based authentication method.
</para>
<para>
doc: improve role option documentation Role option management was changed in Postgres 16. This patch improves the docs around these changes, including CREATE ROLE's INHERIT option, inheritance handling, and grant's ability to change role options. Discussion: https://postgr.es/m/Zab9GiV63EENDcWG@momjian.us Co-authored-by: David G. Johnston Backpatch-through: 16
2024-02-01 12:11:53 +01:00
The role attributes defined here are non-inheritable, i.e., being a
member of a role with, e.g., <literal>CREATEDB</literal> will not
allow the member to create new databases even if the membership grant
has the <literal>INHERIT</literal> option. Of course, if the membership
grant has the <literal>SET</literal> option the member role would be able to
<link linkend="sql-set-role"><command>SET ROLE</command></link> to the
createdb role and then create a new database.
</para>
<para>
The membership grants created by the
<literal>IN ROLE</literal>, <literal>ROLE</literal>, and <literal>ADMIN</literal>
clauses have the role executing this command as the grantee.
Update administrator's guide chapters for ROLEs patch.
2005-08-15 01:35:38 +02:00
</para>
<para>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
The <literal>INHERIT</literal> attribute is the default for reasons of backwards
Basic documentation for ROLEs. The user-manag chapter still needs to be rewritten, but at least the reference pages are reasonably sane.
2005-07-27 01:24:02 +02:00
compatibility: in prior releases of <productname>PostgreSQL</productname>,
users always had access to all privileges of groups they were members of.
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
However, <literal>NOINHERIT</literal> provides a closer match to the semantics
Basic documentation for ROLEs. The user-manag chapter still needs to be rewritten, but at least the reference pages are reasonably sane.
2005-07-27 01:24:02 +02:00
specified in the SQL standard.
</para>
<para>
<productname>PostgreSQL</productname> includes a program <xref
Convert documentation to DocBook XML Since some preparation work had already been done, the only source changes left were changing empty-element tags like <xref linkend="foo"> to <xref linkend="foo"/>, and changing the DOCTYPE. The source files are still named *.sgml, but they are actually XML files now. Renaming could be considered later. In the build system, the intermediate step to convert from SGML to XML is removed. Everything is build straight from the source files again. The OpenSP (or the old SP) package is no longer needed. The documentation toolchain instructions are updated and are much simpler now. Peter Eisentraut, Alexander Lakhin, Jürgen Purtz
2017-11-23 15:39:47 +01:00
linkend="app-createuser"/> that has
Basic documentation for ROLEs. The user-manag chapter still needs to be rewritten, but at least the reference pages are reasonably sane.
2005-07-27 01:24:02 +02:00
the same functionality as <command>CREATE ROLE</command> (in fact,
it calls this command) but can be run from the command shell.
</para>
Add per-user and per-database connection limit options. This patch also includes preliminary update of pg_dumpall for roles. Petr Jelinek, with review by Bruce Momjian and Tom Lane.
2005-07-31 19:19:22 +02:00
<para>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
The <literal>CONNECTION LIMIT</literal> option is only enforced approximately;
Add per-user and per-database connection limit options. This patch also includes preliminary update of pg_dumpall for roles. Petr Jelinek, with review by Bruce Momjian and Tom Lane.
2005-07-31 19:19:22 +02:00
if two new sessions start at about the same time when just one
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
connection <quote>slot</quote> remains for the role, it is possible that
Add per-user and per-database connection limit options. This patch also includes preliminary update of pg_dumpall for roles. Petr Jelinek, with review by Bruce Momjian and Tom Lane.
2005-07-31 19:19:22 +02:00
both will fail. Also, the limit is never enforced for superusers.
</para>
Add new psql command \password for changing role password with client-side password encryption. Also alter createuser command to the same effect.
2005-12-18 03:17:16 +01:00
<para>
Caution must be exercised when specifying an unencrypted password
with this command. The password will be transmitted to the server
in cleartext, and it might also be logged in the client's command
history or the server log. The command <xref
Convert documentation to DocBook XML Since some preparation work had already been done, the only source changes left were changing empty-element tags like <xref linkend="foo"> to <xref linkend="foo"/>, and changing the DOCTYPE. The source files are still named *.sgml, but they are actually XML files now. Renaming could be considered later. In the build system, the intermediate step to convert from SGML to XML is removed. Everything is build straight from the source files again. The OpenSP (or the old SP) package is no longer needed. The documentation toolchain instructions are updated and are much simpler now. Peter Eisentraut, Alexander Lakhin, Jürgen Purtz
2017-11-23 15:39:47 +01:00
linkend="app-createuser"/>, however, transmits
the password encrypted. Also, <xref linkend="app-psql"/>
Remove unnecessary xref endterm attributes and title ids The endterm attribute is mainly useful when the toolchain does not support automatic link target text generation for a particular situation. In the past, this was required by the man page tools for all reference page links, but that is no longer the case, and it now actually gets in the way of proper automatic link text generation. The only remaining use cases are currently xrefs to refsects.
2010-04-03 09:23:02 +02:00
contains a command
Add new psql command \password for changing role password with client-side password encryption. Also alter createuser command to the same effect.
2005-12-18 03:17:16 +01:00
<command>\password</command> that can be used to safely change the
password later.
</para>
Basic documentation for ROLEs. The user-manag chapter still needs to be rewritten, but at least the reference pages are reasonably sane.
2005-07-27 01:24:02 +02:00
</refsect1>
<refsect1>
<title>Examples</title>
<para>
Create a role that can log in, but don't give it a password:
<programlisting>
CREATE ROLE jonathan LOGIN;
</programlisting>
</para>
<para>
Create a role with a password:
<programlisting>
CREATE USER davide WITH PASSWORD 'jw8s0F4';
</programlisting>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
(<command>CREATE USER</command> is the same as <command>CREATE ROLE</command> except
that it implies <literal>LOGIN</literal>.)
Basic documentation for ROLEs. The user-manag chapter still needs to be rewritten, but at least the reference pages are reasonably sane.
2005-07-27 01:24:02 +02:00
</para>
<para>
Create a role with a password that is valid until the end of 2004.
After one second has ticked in 2005, the password is no longer
valid.
<programlisting>
CREATE ROLE miriam WITH LOGIN PASSWORD 'jw8s0F4' VALID UNTIL '2005-01-01';
</programlisting>
</para>
Remove useless whitespace at end of lines
2010-11-23 21:27:50 +01:00
<para>
Basic documentation for ROLEs. The user-manag chapter still needs to be rewritten, but at least the reference pages are reasonably sane.
2005-07-27 01:24:02 +02:00
Create a role that can create databases and manage roles:
<programlisting>
CREATE ROLE admin WITH CREATEDB CREATEROLE;
Fix a whitespace issue with the man pages There is what may actually be a mistake in our markup. The problem is in a situation like <para> <command>FOO</command> is ... there is strictly speaking a line break before "FOO". In the HTML output, this does not appear to be a problem, but in the man page output, this shows up, so you get double blank lines at odd places. So far, we have attempted to work around this with an XSL hack, but that causes other problems, such as creating run-ins in places like <acronym>SQL</acronym> <command>COPY</command> So fix the problem properly by removing the extra whitespace. I only fixed the problems that affect the man page output, not all the places.
2011-08-07 09:49:45 +02:00
</programlisting></para>
Basic documentation for ROLEs. The user-manag chapter still needs to be rewritten, but at least the reference pages are reasonably sane.
2005-07-27 01:24:02 +02:00
</refsect1>
Remove useless whitespace at end of lines
2010-11-23 21:27:50 +01:00
Basic documentation for ROLEs. The user-manag chapter still needs to be rewritten, but at least the reference pages are reasonably sane.
2005-07-27 01:24:02 +02:00
<refsect1>
<title>Compatibility</title>
<para>
The <command>CREATE ROLE</command> statement is in the SQL standard,
but the standard only requires the syntax
<synopsis>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
CREATE ROLE <replaceable class="parameter">name</replaceable> [ WITH ADMIN <replaceable class="parameter">role_name</replaceable> ]
Basic documentation for ROLEs. The user-manag chapter still needs to be rewritten, but at least the reference pages are reasonably sane.
2005-07-27 01:24:02 +02:00
</synopsis>
Multiple initial administrators, and all the other options of
<command>CREATE ROLE</command>, are
<productname>PostgreSQL</productname> extensions.
</para>
Remove useless whitespace at end of lines
2010-11-23 21:27:50 +01:00
Basic documentation for ROLEs. The user-manag chapter still needs to be rewritten, but at least the reference pages are reasonably sane.
2005-07-27 01:24:02 +02:00
<para>
The SQL standard defines the concepts of users and roles, but it
regards them as distinct concepts and leaves all commands defining
users to be specified by each database implementation. In
<productname>PostgreSQL</productname> we have chosen to unify
users and roles into a single kind of entity. Roles therefore
have many more optional attributes than they do in the standard.
</para>
<para>
The behavior specified by the SQL standard is most closely approximated
doc: improve role option documentation Role option management was changed in Postgres 16. This patch improves the docs around these changes, including CREATE ROLE's INHERIT option, inheritance handling, and grant's ability to change role options. Discussion: https://postgr.es/m/Zab9GiV63EENDcWG@momjian.us Co-authored-by: David G. Johnston Backpatch-through: 16
2024-02-01 12:11:53 +01:00
creating SQL-standard users as <productname>PostgreSQL</productname>
roles with the <literal>NOINHERIT</literal> option, and SQL-standard
roles as <productname>PostgreSQL</productname> roles with the
<literal>INHERIT</literal> option.
Basic documentation for ROLEs. The user-manag chapter still needs to be rewritten, but at least the reference pages are reasonably sane.
2005-07-27 01:24:02 +02:00
</para>
doc: Move CREATE ROLE's IN GROUP and USER to deprecated Reported-by: t.kitynski@gmail.com Discussion: https://postgr.es/m/167473556945.2667294.2003897901995802549@wrigleys.postgresql.org Backpatch-through: master
2023-10-10 22:44:02 +02:00
<para>
The <literal>USER</literal> clause has the same behavior as
<literal>ROLE</literal> but has been deprecated:
<synopsis>
USER <replaceable class="parameter">role_name</replaceable> [, ...]
</synopsis>
</para>
<para>
The <literal>IN GROUP</literal> clause has the same behavior as <literal>IN
ROLE</literal> but has been deprecated:
<synopsis>
IN GROUP <replaceable class="parameter">role_name</replaceable> [, ...]
</synopsis>
</para>
Basic documentation for ROLEs. The user-manag chapter still needs to be rewritten, but at least the reference pages are reasonably sane.
2005-07-27 01:24:02 +02:00
</refsect1>
<refsect1>
<title>See Also</title>
<simplelist type="inline">
Convert documentation to DocBook XML Since some preparation work had already been done, the only source changes left were changing empty-element tags like <xref linkend="foo"> to <xref linkend="foo"/>, and changing the DOCTYPE. The source files are still named *.sgml, but they are actually XML files now. Renaming could be considered later. In the build system, the intermediate step to convert from SGML to XML is removed. Everything is build straight from the source files again. The OpenSP (or the old SP) package is no longer needed. The documentation toolchain instructions are updated and are much simpler now. Peter Eisentraut, Alexander Lakhin, Jürgen Purtz
2017-11-23 15:39:47 +01:00
<member><xref linkend="sql-set-role"/></member>
<member><xref linkend="sql-alterrole"/></member>
<member><xref linkend="sql-droprole"/></member>
<member><xref linkend="sql-grant"/></member>
<member><xref linkend="sql-revoke"/></member>
<member><xref linkend="app-createuser"/></member>
Add new GUC createrole_self_grant. Can be set to the empty string, or to either or both of "set" or "inherit". If set to a non-empty value, a non-superuser who creates a role (necessarily by relying up the CREATEROLE privilege) will grant that role back to themselves with the specified options. This isn't a security feature, because the grant that this feature triggers can also be performed explicitly. Instead, it's a user experience feature. A superuser would necessarily inherit the privileges of any created role and be able to access all such roles via SET ROLE; with this patch, you can configure createrole_self_grant = 'set, inherit' to provide a similar experience for a user who has CREATEROLE but not SUPERUSER. Discussion: https://postgr.es/m/CA+TgmobN59ct+Emmz6ig1Nua2Q-_o=r6DSD98KfU53kctq_kQw@mail.gmail.com
2023-01-10 18:44:49 +01:00
<member><xref linkend="guc-createrole-self-grant"/></member>
Basic documentation for ROLEs. The user-manag chapter still needs to be rewritten, but at least the reference pages are reasonably sane.
2005-07-27 01:24:02 +02:00
</simplelist>
</refsect1>
</refentry>