| From: | Stephen Frost <sfrost(at)snowman(dot)net> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, Joe Conway <mail(at)joeconway(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Multi-tenancy with RLS |
| Date: | 2015-10-09 03:04:46 |
| Message-ID: | 20151009030446.GF3685@tamriel.snowman.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> We've got one reloption for views already - security_barrier. Maybe
> we could have another one that effectively changes a particular view
> from "security definer" as it is today to "security invoker".
As I recall, there was a previous suggestion (honestly, I thought it was
your idea) to have a reloption which made views "fully" security
definer, in that functions in the view definition would run as the view
owner instead of the view invoker.
I liked that idea, though we would need to have a function to say "who
is the 'outer' user?" (CURRENT_USER always being the owner with the
above described reloption).
I'm less sure about the idea of having a view which runs entirely as the
view invoker, but I'm not against it either.
I do think both of those are independent of supporting policies for
views and foreign tables though, which we'd want even if we had
reloptions for the above ideas.
Thanks!
Stephen
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Noah Misch | 2015-10-09 03:26:49 | Re: [BUGS] BUG #13611: test_postmaster_connection failed (Windows, listen_addresses = '0.0.0.0' or '::') |
| Previous Message | Etsuro Fujita | 2015-10-09 03:00:30 | Re: Foreign join pushdown vs EvalPlanQual |