Re: table partitioning and access privileges

On 2020/01/22 16:54, Amit Langote wrote:
> Fujii-san,
>
> Thanks for taking a look.
>
> On Fri, Jan 10, 2020 at 10:29 AM Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>> On Tue, Jan 7, 2020 at 5:15 PM Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
>>> I tend to agree that TRUNCATE's permission model for inheritance
>>> should be consistent with that for the other commands. How about the
>>> attached patch toward that end?
>>
>> Thanks for the patch!
>>
>> The patch basically looks good to me.
>>
>> +GRANT SELECT (f1, fz), UPDATE (fz) ON atestc TO regress_priv_user2;
>> +REVOKE TRUNCATE ON atestc FROM regress_priv_user2;
>>
>> These seem not to be necessary for the test.
>
> You're right. Removed in the attached updated patch.

Thanks for updating the patch! Barring any objection,
I will commit this fix and backport it to all supported versions.

>> BTW, I found that LOCK TABLE on the parent table checks the permission
>> of its child tables. This also needs to be fixed (as a separate patch)?
>
> Commit ac33c7e2c13 and a past discussion ([1], [2], resp.) appear to
> disagree with that position, but I would like to agree with you
> because the behavior you suggest would be consistent with other
> commands. So, I'm attaching a patch for that too, although it would
> be better to hear more opinions before accepting it.

Yes. I'd like to hear more opinion about this. But
since the document explains "Inherited queries perform access
permission checks on the parent table only." in ddl.sgml,
that also seems a bug to fix...

Regards,

--
Fujii Masao
NTT DATA CORPORATION
Advanced Platform Technology Group
Research and Development Headquarters