public inbox for [email protected]
help / color / mirror / Atom feedFrom: Shinya Kato <[email protected]>
To: Swaha Miller <[email protected]>
Cc: Laurenz Albe <[email protected]>
Cc: [email protected]
Subject: Re: Question about role attributes docs
Date: Thu, 17 Mar 2022 17:56:58 +0900
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAPXknY4aqZZA34OPojPstXSpK8SSCGUt8aSZ_V5UE-Gt+6At6g@mail.gmail.com>
References: <[email protected]>
<[email protected]>
<[email protected]>
<CAPXknY4aqZZA34OPojPstXSpK8SSCGUt8aSZ_V5UE-Gt+6At6g@mail.gmail.com>
On 2022-02-16 06:39, Swaha Miller wrote:
> On Tue, Feb 15, 2022 at 1:32 PM Shinya Kato
> <[email protected]> wrote:
>
>> On 2022-01-12 02:07, Laurenz Albe wrote:
>>> On Tue, 2022-01-11 at 16:40 +0900, Shinya Kato wrote:
>>>> I have a question about the documentation on ROLE.
>>>>
>>>> According to [1], INHERIT and BYPASSRLS can be specified when
>>>> executing
>>>> the CREATE ROLE command. However, there is no such description in
>> Role
>>>> Attributes in [2]. Are these concepts different from Role
>> Attributes?
>>>> Or
>>>> are they just not documented? If they need to be documented, I'll
>>
>>>> create
>>>> a patch.
>>>>
>>>> [1] https://www.postgresql.org/docs/devel/sql-createrole.html
>>>> [2] https://www.postgresql.org/docs/devel/role-attributes.html
>>>
>>> I think that is indeed an omission, and adding documentation would
>> be a
>>> good idea.
>> Thanks! I created the patch, and attached it.
>>
>>> On the other hand, a lot of that information is more or less
>>> a duplicate of the CREATE ROLE documentation. I wonder if the
>> latter
>>> page could be removed altogether.
>> I think there is certainly a lot of overlap. However, I think that
>> the
>> SQL commands page and the database roles page should exist
>> separately,
>> and should be maintained as they are because there are parts that do
>> not
>> overlap (for example, IN ROLE and ADMIN).
>>
>> --
>> Regards,
>>
>> --
>> Shinya Kato
>> Advanced Computing Technology Center
>> Research and Development Headquarters
>> NTT DATA CORPORATION
>
> May I suggest replacing the following verbiage in your patch
> + A role is needed to permission to inherit privileges of roles
> it is a member of.
> + (except for superusers, since those bypass all permission
> checks).
> + If not specified, <literal>INHERIT</literal> is the default,
> so to create such a role, use either:
>
> with clearer wording such as the following:
>
> A role can explicitly be restricted at time of creation from
> inheriting privileges of
> roles it is a member of (except for superusers, since those bypass all
> permission checks.)
> Restricting privileges is done by the <literal>NOINHERIT</literal>
> option.
> If no option is specified, <literal>INHERIT</literal> is the default.
> So to create a role that inherits
>
> privileges, use either:
>
> Regards,
>
> Swaha Miller
> Amazon Web Services
Thank you for the review, and sorry for late reply.
I fixed it.
--
Regards,
--
Shinya Kato
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
Attachments:
[text/x-diff] v2-add-role-attributes-to-docs.patch (2.2K, 2-v2-add-role-attributes-to-docs.patch)
download | inline diff:
diff --git a/doc/src/sgml/user-manag.sgml b/doc/src/sgml/user-manag.sgml
index 9067be1d9c..fb9f382c92 100644
--- a/doc/src/sgml/user-manag.sgml
+++ b/doc/src/sgml/user-manag.sgml
@@ -236,6 +236,44 @@ CREATE USER <replaceable>name</replaceable>;
</para>
</listitem>
</varlistentry>
+
+ <varlistentry>
+ <term>inheritance of privileges<indexterm><primary>role</primary><secondary>privilege to inherit</secondary></indexterm></term>
+ <listitem>
+ <para>
+ A role can explicitly be restricted at time of creation from inheriting privileges of
+ roles it is a member of (except for superusers, since those bypass all permission checks.)
+ Restricting privileges is done by the <literal>NOINHERIT</literal> option.
+ If no option is specified, <literal>INHERIT</literal> is the default. So to create a role that inherits
+ privileges, use either:
+<programlisting>
+CREATE ROLE <replaceable>name</replaceable> INHERIT;
+CREATE ROLE <replaceable>name</replaceable>;
+</programlisting>
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>bypass row-level security<indexterm><primary>role</primary><secondary>privilege to bypass</secondary></indexterm></term>
+ <listitem>
+ <para>
+ A role must be explicitly given permission to bypass row-level security (RLS) policy.
+ (except for superusers, since those bypass all permission checks).
+ To create such a role, use <literal>CREATE ROLE <replaceable>name</replaceable> BYPASSRLS</literal>.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>connection limit<indexterm><primary>role</primary><secondary>privilege to limit connection</secondary></indexterm></term>
+ <listitem>
+ <para>
+ Connection limit can specify how many concurrent connections a role can make.
+ -1 (the default) means no limit. To create such a role, use <literal>CREATE ROLE <replaceable>name</replaceable> CONNECTION LIMIT<replaceable> connlimit</replaceable> LOGIN</literal>.
+ </para>
+ </listitem>
+ </varlistentry>
</variablelist>
A role's attributes can be modified after creation with
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: Question about role attributes docs
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox