Re: Improving RLS planning
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Stephen Frost <sfrost@snowman.net>
Cc: Dean Rasheed <dean.a.rasheed@gmail.com>,
PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2016-11-08T14:45:18Z
Lists: pgsql-hackers
Stephen Frost <sfrost@snowman.net> writes: > * Tom Lane (tgl@sss.pgh.pa.us) wrote: >> * Since the planner is now depending on Query.hasRowSecurity to be set >> whenever there are any securityQuals, I put in an Assert about that, >> and promptly found three places in prepjointree.c and the rewriter where >> we'd been failing to set it. I have not looked to see if these represent >> live bugs in existing releases, but they might. Or am I misunderstanding >> what the flag is supposed to mean? > They're independent, actually. securityQuals can be set via either > security barrier view or from RLS, while hasRowSecurity is specifically > for the RLS case. The reason for the distinction is that changing your > role isn't going to impact security barrier views at all, while it could > impact what RLS policies are used. See extract_query_dependencies(). OK. In that case I'll need to adjust the patch so that the planner keeps its own flag about whether the query contains any securityQuals; that's easy enough. But I'm still suspicious that the three places I found may represent bugs in the management of Query.hasRowSecurity. regards, tom lane
Commits
-
Improve RLS planning by marking individual quals with security levels.
- 215b43cdc8d6 10.0 landed