RLS bug in expanding security quals - Mailing list pgsql-hackers

From Haribabu Kommi
Subject RLS bug in expanding security quals
Date
Msg-id CAJrrPGf49McMA=jAThY1rSdjKvad3Jj5mVn1_OD9A9M5v2PeSQ@mail.gmail.com
Whole thread Raw
Responses Re: RLS bug in expanding security quals  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers

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.

SELECT (u_grantor.rolname) AS grantor,  (grantee.rolname) AS grantee                                                     FROM  pg_authid u_grantor,                                                                                                                 ( SELECT pg_authid.oid,                                                                                                                                         pg_authid.rolname                                                                                                                      FROM pg_authid                                                                                                                               UNION ALL                                                                                                                                               SELECT (0)::oid AS oid,                                                                                                                                  'PUBLIC'::name) grantee(oid, rolname)                                                                               WHERE (grantee.rolname = 'PUBLIC'::name)

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.

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.

Any ideas how to handle this problem?

Regards,
Hari Babu
Fujitsu Australia

[1] - http://www.postgresql.org/message-id/CAJrrPGd2cf4hz_edPX+uqJV1Ytkajs_wJDiwj7pzZUUqwOugEw@mail.gmail.com
Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: cash_mul_int8 / cash_div_int8
Next
From: Stephen Frost
Date:
Subject: Re: RLS bug in expanding security quals