Re: A bug with ExecCheckPermissions

Sergey Shinderuk <s.shinderuk@postgrespro.ru>

From: Sergey Shinderuk <s.shinderuk@postgrespro.ru>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>, Amit Langote <amitlangote09@gmail.com>
Cc: o.tselebrovskiy@postgrespro.ru, pgsql-hackers@postgresql.org
Date: 2023-02-09T09:14:44Z
Lists: pgsql-hackers

Attachments

On 08.02.2023 21:23, Alvaro Herrera wrote:
> On 2023-Feb-08, Amit Langote wrote:
> 
>> On Wed, Feb 8, 2023 at 16:19 Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> 
>>> I think we should also patch ExecCheckPermissions to use forboth(),
>>> scanning the RTEs as it goes over the perminfos, and make sure that the
>>> entries are consistent.
>>
>> Hmm, we can’t use forboth here, because not all RTEs have the corresponding
>> RTEPermissionInfo, inheritance children RTEs, for example.
> 
> Doh, of course.
> 
>> Also, it doesn’t make much sense to reinstate the original loop over
>> range table and fetch the RTEPermissionInfo for the RTEs with non-0
>> perminfoindex, because the main goal of the patch was to make
>> ExecCheckPermissions() independent of range table length.
> 
> Yeah, I'm thinking in a mechanism that would allow us to detect bugs in
> development builds — no need to have it run in production builds.
> However, I can't see any useful way to implement it.
>


Maybe something like the attached would do?


-- 
Sergey Shinderuk		https://postgrespro.com/

Commits

  1. Fix sepgsql expected test output

  2. Fix ExecCheckPermissions call in RI_Initial_Check