Re: table partitioning and access privileges

On Fri, Jan 31, 2020 at 1:28 AM Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> wrote:
> On 2020/01/31 1:02, Tom Lane wrote:
> > Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> writes:
> >> Thanks for updating the patch! Barring any objection,
> >> I will commit this fix and backport it to all supported versions.
> >
> > Sorry for not having paid closer attention to this thread, but ...
> > is back-patching this behavioral change really a good idea?
> >
> > It's not that hard to imagine that somebody is expecting the old
> > behavior and will complain that we broke their application's security.
> > So I'd have thought it better to fix only in HEAD, with a
> > compatibility warning in the v13 release notes.
> >
> > I'm afraid it's much more likely that people will complain about
> > making such a change in a minor release than that they will be
> > happy about it. It's particularly risky to be making it in what
> > will be the last 9.4.x release, because we will not have any
> > opportunity to undo it in that branch if there is pushback.
>
> 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?

Thanks,
Amit