Re: RLS bug in expanding security quals

Haribabu,

* Haribabu Kommi (kommi(dot)haribabu(at)gmail(dot)com) wrote:
> During the testing of multi-tenancy feature from system catalog views, that
> is described in [1], found a problem in executing "user_privileges" view
> from information_schema. The following is the minimal test sql that
> reproduces the problem.

Interesting, thanks.

> >From further analysis, I found that the same issue can happen with user
> tables also. Attached
> rls_failure.sql file has test steps to reproduce the issue.

Just to make sure we're on the same page, this results in this assertion
being tripped:

TRAP: FailedAssertion("!(var->varattno <= rel->max_attr)", File:
"/home/sfrost/git/pg/dev/postgresql/src/backend/optimizer/path/costsize.c",
Line: 4152)

Due to var->varattno being 1 and rel->max_attr being 0.

> The problem is, while expanding security quals in
> function expand_security_quals, the relation
> u_grantor and test_tbl are to be expanded as they are the relations which
> have security quals.
>
> Following is the debug information of parse->rtable that shows the details
> of each RangeTblEntry.
>
> $69 = {type = T_Alias, aliasname = 0x19bd870 "u_grantor", colnames =
> 0x19bd890}
> (gdb) p *((RangeTblEntry
> *)parse->rtable->head->next->next->next->data.ptr_value)->eref
> $70 = {type = T_Alias, aliasname = 0x19bffc8 "grantee", colnames =
> 0x19bffe0}
> (gdb) p *((RangeTblEntry
> *)parse->rtable->head->next->next->next->next->data.ptr_value)->eref
> $71 = {type = T_Alias, aliasname = 0x19c3a60 "*SELECT* 1", colnames =
> 0x19c3a80}
> (gdb) p *((RangeTblEntry
> *)parse->rtable->head->next->next->next->next->next->data.ptr_value)->eref
> $72 = {type = T_Alias, aliasname = 0x19c40d8 "*SELECT* 2", colnames =
> 0x19c40f8}
> (gdb) p *((RangeTblEntry
> *)parse->rtable->head->next->next->next->next->next->next->data.ptr_value)->eref
> $73 = {type = T_Alias, aliasname = 0x19c4648 "test_tbl", colnames =
> 0x19c4668}
>
>
> In expand_security_qual function, the security_barrier_replace_vars
> function is called to prepare the context.targetlist. But this function
> doesn't generate targetlist for test_tbl RangeTblEntry. Because of this
> reason, while accessing the targetlist, it fails and throws an error.
>
> In case if the policy is changed to below other than specified in the
> rls_failure.sql
>
> create policy test_tbl_policy on test_tbl for select using(true);
>
> the query execution passes, because in expand_security_quals function,
> the rangeTableEntry_used function returns false for test_tbl entry, thus it
> avoids expanding the security qual.

Interesting.

> Any ideas how to handle this problem?

It's quite late here, but I'll take a look at this in more depth
tomorrow.

Based on what the Assert's testing, I took an educated guess and tried
running without the UNION ALL, which appeared to work correctly.

Thanks!

Stephen