RLS bug in expanding security quals
| От | Haribabu Kommi |
|---|---|
| Тема | RLS bug in expanding security quals |
| Дата | |
| Msg-id | CAJrrPGf49McMA=jAThY1rSdjKvad3Jj5mVn1_OD9A9M5v2PeSQ@mail.gmail.com обсуждение исходный текст |
| Ответы |
Re: RLS bug in expanding security quals
(Stephen Frost <sfrost@snowman.net>)
|
| Список | 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 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
Regards,
Hari Babu
Fujitsu Australia
[1] - http://www.postgresql.org/message-id/CAJrrPGd2cf4hz_edPX+uqJV1Ytkajs_wJDiwj7pzZUUqwOugEw@mail.gmail.com
Вложения
В списке pgsql-hackers по дате отправления: