Re: [v9.3] Row-Level Security
От | Dean Rasheed |
---|---|
Тема | Re: [v9.3] Row-Level Security |
Дата | |
Msg-id | CAEZATCUz7+QVudWbgnSrv-KbHRPq33Z07vdv1eYn+cDRMbazzQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [v9.3] Row-Level Security (Kohei KaiGai <kaigai@kaigai.gr.jp>) |
Ответы |
Re: [v9.3] Row-Level Security
|
Список | pgsql-hackers |
On 8 October 2012 15:57, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote: > The attached patch is a refreshed version towards the latest master branch, > to fix up patch conflicts. > Here is no other difference from the previous revision. > > Thanks, > I had another look at this over the weekend and I found couple of additional problems (test cases attached): 1). It is possible to define a RLS qual that refers back to the table that it's defined on, in such a way that causes infinite recursion in the planner, giving "ERROR: stack depth limit exceeded". I think it would be preferable to trap this and report a more meaningful error back to the user, along similar lines to a self-referencing view. 2). In other cases it is possible to define a RLS qual that refers to another table with a RLS qual in such a way that the second table's RLS qual is not checked, thus allowing a user to bypass the security check. 3). If a RLS qual refers to a view it errors, since the RLS quals are added after rule expansion, and so the view is not rewritten. To me this suggests that perhaps the expansion of RLS quals should be done in the rewriter. I've not thought that through in any detail, but ISTM that a RIR rule could add a table with a RLS qual, and a RLS qual could add a relation with a RIR rule that needs expanding, and so the 2 need to be processed together. This could also make use of the existing recursion-checking code in the rewriter. Regards, Dean
Вложения
В списке pgsql-hackers по дате отправления: