From: Fujii Masao <masao.fujii@oss.nttdata.com>
To: Amit Langote <amitlangote09@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Fujii Masao <masao.fujii@gmail.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: table partitioning and access privileges
Date: Mon, 3 Feb 2020 14:07:35 +0900
Message-ID: <79ee190f-8219-6091-d2e5-ffae1bcf8d6e@oss.nttdata.com> (raw)
In-Reply-To: <CA+HiwqHpNqL9uL13pjrC6Ou2T-WnhoGftb6WXBPkK9nprex3Eg@mail.gmail.com>
References: <CAHGQGwFHdSvifhJE+-GSNqUHSfbiKxaeQQ7HGcYz6SC2n_oDcg@mail.gmail.com>
<6218.1577388354@sss.pgh.pa.us>
<CA+HiwqGCQLKizA+Voyw3GjRv0q8t9adS2YFGmw6GzAbRb+yazg@mail.gmail.com>
<CAHGQGwE+GauyG7POtRfRwwthAGwTjPQYdFHR97+LzA4RHGnJxA@mail.gmail.com>
<CA+HiwqF55uZK6znXq7=qP-LS5HQkcjGEvCHxGUjYhJGq=z9nDg@mail.gmail.com>
<3546b691-b744-12c9-fd2f-7dc31c3c030e@oss.nttdata.com>
<21015.1580400165@sss.pgh.pa.us>
<d686c99b-6567-9c6c-4f41-129a106afdb5@oss.nttdata.com>
<CA+HiwqHfTnMU6SUkyHxCmpHUKk7ERLHCR3vZVq19ZOQBjPBLmQ@mail.gmail.com>
<f3dba4e6-ddeb-5126-b9a6-13a04c7c23dc@oss.nttdata.com>
<CA+HiwqHpNqL9uL13pjrC6Ou2T-WnhoGftb6WXBPkK9nprex3Eg@mail.gmail.com>
On 2020/02/03 11:05, Amit Langote wrote:
> On Fri, Jan 31, 2020 at 9:39 PM Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
>> On 2020/01/31 13:38, Amit Langote wrote:
>>> On Fri, Jan 31, 2020 at 1:28 AM Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
>>>> Fair enough. I finally did back-patch because the behavior is clearly
>>>> documented and I failed to hear the opinions to object the back-patch.
>>>> But I should have heard and discussed such risks more.
>>>>
>>>> I'm OK to revert all those back-patch. Instead, probably the document
>>>> should be updated in old branches.
>>>
>>> I could find only this paragraph in the section on inheritance that
>>> talks about how access permissions work:
>>>
>>> 9.4:
>>>
>>> "Note how table access permissions are handled. Querying a parent
>>> table can automatically access data in child tables without further
>>> access privilege checking. This preserves the appearance that the data
>>> is (also) in the parent table. Accessing the child tables directly is,
>>> however, not automatically allowed and would require further
>>> privileges to be granted."
>>>
>>> 9.5-12:
>>>
>>> "Inherited queries perform access permission checks on the parent
>>> table only. Thus, for example, granting UPDATE permission on the
>>> cities table implies permission to update rows in the capitals table
>>> as well, when they are accessed through cities. This preserves the
>>> appearance that the data is (also) in the parent table. But the
>>> capitals table could not be updated directly without an additional
>>> grant. In a similar way, the parent table's row security policies (see
>>> Section 5.7) are applied to rows coming from child tables during an
>>> inherited query. A child table's policies, if any, are applied only
>>> when it is the table explicitly named in the query; and in that case,
>>> any policies attached to its parent(s) are ignored."
>>>
>>> Do you mean that the TRUNCATE exception should be noted here?
>>
>> Yes, that's what I was thinking.
>
> Okay. How about the attached?
Thanks for the patches! You added the note just after the description
about row level security on inherited table, but isn't it better to
add it before that? Attached patch does that. Thought?
> Maybe, we should also note the LOCK TABLE exception?
Yes.
Regards,
--
Fujii Masao
NTT DATA CORPORATION
Advanced Platform Technology Group
Research and Development Headquarters
Attachments:doc-inh-trunc-perms-95-12_fujii.patch (text/plain, 1.1K) downloaddiff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgmlindex d88651df9e..7550d03f27 100644--- a/doc/src/sgml/ddl.sgml+++ b/doc/src/sgml/ddl.sgml@@ -3384,7 +3384,15 @@ VALUES ('Albany', NULL, NULL, 'NY');
accessed through <structname>cities</structname>. This preserves the appearance
that the data is (also) in the parent table. But
the <structname>capitals</structname> table could not be updated directly
- without an additional grant. In a similar way, the parent table's row+ without an additional grant. Two exceptions to this rule are+ <command>TRUNCATE</command> and <command>LOCK TABLE</command>,+ where permissions on the child tables are always checked,+ whether they are processed directly or recursively via those commands+ performed on the parent table.+ </para>++ <para>+ In a similar way, the parent table's row
security policies (see <xref linkend="ddl-rowsecurity"/>) are applied to
rows coming from child tables during an inherited query. A child table's
policies, if any, are applied only when it is the table explicitly named
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: pgsql-hackers@postgresql.org
Cc: masao.fujii@oss.nttdata.com, amitlangote09@gmail.com, tgl@sss.pgh.pa.us, masao.fujii@gmail.com
Subject: Re: table partitioning and access privileges
In-Reply-To: <79ee190f-8219-6091-d2e5-ffae1bcf8d6e@oss.nttdata.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox