From: | Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com> |
---|---|
To: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | RLS bug in expanding security quals |
Date: | 2015-10-08 03:22:40 |
Message-ID: | CAJrrPGf49McMA=jAThY1rSdjKvad3Jj5mVn1_OD9A9M5v2PeSQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
Attachment | Content-Type | Size |
---|---|---|
rls_failure.sql | application/octet-stream | 1.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2015-10-08 03:54:57 | Re: RLS bug in expanding security quals |
Previous Message | Michael Paquier | 2015-10-08 02:55:00 | Re: cash_mul_int8 / cash_div_int8 |