pg.ddx.io pgsql-bugs@postgresql.org mailing list archive
help / color / mirror / Atom feedBUG #17549: wrong index scan plan with RLS
2+ messages / 2 participants
[nested] [flat]
* BUG #17549: wrong index scan plan with RLS
@ 2022-07-13 11:45 PG Bug reporting form <noreply@postgresql.org>
2022-07-13 14:27 ` Re: BUG #17549: wrong index scan plan with RLS Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 2+ messages in thread
From: PG Bug reporting form @ 2022-07-13 11:45 UTC (permalink / raw)
To: pgsql-bugs@lists.postgresql.org; +Cc: 875941708@qq.com
The following bug has been logged on the website:
Bug reference: 17549
Logged by: Zhao Rui
Email address: 875941708@qq.com
PostgreSQL version: 14.4
Operating system: All
Description:
You can reproduce in this way:
create table abc (a integer, b text);
insert into abc select (random()*(10^4))::integer, (random()*(10^4))::text
from generate_series(1,100000);
create index on abc(a, lower(b));
ALTER TABLE abc enable ROW LEVEL SECURITY;
ALTER TABLE abc FORCE ROW LEVEL SECURITY;
CREATE POLICY abc_id_iso_ply on abc to CURRENT_USER USING (a =
(current_setting('app.a'::text))::int);
# for bypass user, index scan works fine
explain analyse select * from abc where a=1 and lower(b)='1234';
Index Scan using abc_a_lower_idx on abc
Index Cond: ((a = 1) AND (lower(b) = '1234'::text))
# for RLS user, index scan can only use column a, and filter by lower(b)
set app.a=1;
explain analyse select * from abc where a=1 and lower(b)='1234';
Index Scan using abc_a_lower_idx on abc
Index Cond: (a = 1)
Filter: (lower(b) = '1234'::text)
This only occurs when using non-leak-proof functional index. Everything
works fine in following way:
create index on abc(a, b);
explain analyse select * from abc where a=1 and b='1234';
I think crucial function is restriction_is_securely_promotable. Maybe it is
too strict to reject normal clause match.
Could you please recheck RLS with functional index?
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: BUG #17549: wrong index scan plan with RLS
2022-07-13 11:45 BUG #17549: wrong index scan plan with RLS PG Bug reporting form <noreply@postgresql.org>
@ 2022-07-13 14:27 ` Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 2+ messages in thread
From: Tom Lane @ 2022-07-13 14:27 UTC (permalink / raw)
To: 875941708@qq.com; +Cc: pgsql-bugs@lists.postgresql.org
PG Bug reporting form <noreply@postgresql.org> writes:
> # for RLS user, index scan can only use column a, and filter by lower(b)
> set app.a=1;
> explain analyse select * from abc where a=1 and lower(b)='1234';
> Index Scan using abc_a_lower_idx on abc
> Index Cond: (a = 1)
> Filter: (lower(b) = '1234'::text)
AFAICS this is operating as designed. It's unsafe to apply the
non-leakproof condition until we've verified that the row has a = 1.
In the particular case shown here, it might be all right to do it,
but cases such as bitmap indexscans or lossy index opclasses could
result in live re-evaluations of the indexqual conditions at some
rows. So we can't safely allow lower(b) to become part of the
indexquals.
regards, tom lane
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2022-07-13 14:27 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2022-07-13 11:45 BUG #17549: wrong index scan plan with RLS PG Bug reporting form <noreply@postgresql.org>
2022-07-13 14:27 ` Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox