Re: [v9.4] row level security
От | Tom Lane |
---|---|
Тема | Re: [v9.4] row level security |
Дата | |
Msg-id | 2620.1378308159@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [v9.4] row level security (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [v9.4] row level security
Re: [v9.4] row level security Re: [v9.4] row level security |
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > On Wed, Sep 4, 2013 at 10:50 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Robert Haas <robertmhaas@gmail.com> writes: >>> Right. IMHO, this new feature should be similarly simple: when an >>> unprivileged user references a table, treat that as a reference to a >>> leakproof view over the table, with the RLS qual injected into the >>> view. >> And for insert/update/delete, we do what exactly? > The same mechanism will prevent UPDATE and DELETE from seeing any rows > the user shouldn't be able to touch. No, it won't, because we don't support direct update/delete on views (and if you look, you'll notice the auto-updatable-view stuff doesn't think a security-barrier view is auto-updatable). AFAICT, to deal with update/delete the RLS patch needs to constrain order of qual application without the crutch of having a separate level of subquery; and it's that behavior that I have zero confidence in, either as to whether it works as submitted or as to our odds of not breaking it in the future. regards, tom lane
В списке pgsql-hackers по дате отправления: