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: | Raw Message | Whole Thread | 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 |