Subject: Re: table partitioning and access privileges
To: Amit Langote <amitlangote09@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Fujii Masao <masao.fujii@gmail.com>,
 PostgreSQL-development <pgsql-hackers@postgresql.org>
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>
From: Fujii Masao <masao.fujii@oss.nttdata.com>
Message-ID: <79ee190f-8219-6091-d2e5-ffae1bcf8d6e@oss.nttdata.com>
Date: Mon, 3 Feb 2020 14:07:35 +0900
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.4.2
MIME-Version: 1.0
In-Reply-To: 
 <CA+HiwqHpNqL9uL13pjrC6Ou2T-WnhoGftb6WXBPkK9nprex3Eg@mail.gmail.com>
Content-Type: multipart/mixed;
 boundary="------------C6E1B90C89897C9FD9388D68"
Content-Language: en-US
Precedence: bulk

This is a multi-part message in MIME format.
--------------C6E1B90C89897C9FD9388D68
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit


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

--------------C6E1B90C89897C9FD9388D68
Content-Type: text/plain; charset=UTF-8; x-mac-type="0"; x-mac-creator="0";
 name="doc-inh-trunc-perms-95-12_fujii.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="doc-inh-trunc-perms-95-12_fujii.patch"

ZGlmZiAtLWdpdCBhL2RvYy9zcmMvc2dtbC9kZGwuc2dtbCBiL2RvYy9zcmMvc2dtbC9kZGwu
c2dtbAppbmRleCBkODg2NTFkZjllLi43NTUwZDAzZjI3IDEwMDY0NAotLS0gYS9kb2Mvc3Jj
L3NnbWwvZGRsLnNnbWwKKysrIGIvZG9jL3NyYy9zZ21sL2RkbC5zZ21sCkBAIC0zMzg0LDcg
KzMzODQsMTUgQEAgVkFMVUVTICgnQWxiYW55JywgTlVMTCwgTlVMTCwgJ05ZJyk7CiAgICBh
Y2Nlc3NlZCB0aHJvdWdoIDxzdHJ1Y3RuYW1lPmNpdGllczwvc3RydWN0bmFtZT4uICBUaGlz
IHByZXNlcnZlcyB0aGUgYXBwZWFyYW5jZQogICAgdGhhdCB0aGUgZGF0YSBpcyAoYWxzbykg
aW4gdGhlIHBhcmVudCB0YWJsZS4gIEJ1dAogICAgdGhlIDxzdHJ1Y3RuYW1lPmNhcGl0YWxz
PC9zdHJ1Y3RuYW1lPiB0YWJsZSBjb3VsZCBub3QgYmUgdXBkYXRlZCBkaXJlY3RseQotICAg
d2l0aG91dCBhbiBhZGRpdGlvbmFsIGdyYW50LiAgSW4gYSBzaW1pbGFyIHdheSwgdGhlIHBh
cmVudCB0YWJsZSdzIHJvdworICAgd2l0aG91dCBhbiBhZGRpdGlvbmFsIGdyYW50LiAgVHdv
IGV4Y2VwdGlvbnMgdG8gdGhpcyBydWxlIGFyZQorICAgPGNvbW1hbmQ+VFJVTkNBVEU8L2Nv
bW1hbmQ+IGFuZCA8Y29tbWFuZD5MT0NLIFRBQkxFPC9jb21tYW5kPiwKKyAgIHdoZXJlIHBl
cm1pc3Npb25zIG9uIHRoZSBjaGlsZCB0YWJsZXMgYXJlIGFsd2F5cyBjaGVja2VkLAorICAg
d2hldGhlciB0aGV5IGFyZSBwcm9jZXNzZWQgZGlyZWN0bHkgb3IgcmVjdXJzaXZlbHkgdmlh
IHRob3NlIGNvbW1hbmRzCisgICBwZXJmb3JtZWQgb24gdGhlIHBhcmVudCB0YWJsZS4KKyAg
PC9wYXJhPgorCisgIDxwYXJhPgorICAgSW4gYSBzaW1pbGFyIHdheSwgdGhlIHBhcmVudCB0
YWJsZSdzIHJvdwogICAgc2VjdXJpdHkgcG9saWNpZXMgKHNlZSA8eHJlZiBsaW5rZW5kPSJk
ZGwtcm93c2VjdXJpdHkiLz4pIGFyZSBhcHBsaWVkIHRvCiAgICByb3dzIGNvbWluZyBmcm9t
IGNoaWxkIHRhYmxlcyBkdXJpbmcgYW4gaW5oZXJpdGVkIHF1ZXJ5LiAgQSBjaGlsZCB0YWJs
ZSdzCiAgICBwb2xpY2llcywgaWYgYW55LCBhcmUgYXBwbGllZCBvbmx5IHdoZW4gaXQgaXMg
dGhlIHRhYmxlIGV4cGxpY2l0bHkgbmFtZWQK
--------------C6E1B90C89897C9FD9388D68--