On 10/08/2015 11:04 PM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.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'd love to see a way for views to behave in an entirely view definer or
entirely view invoker way. The current mixed mode is bad/confusing IMHO,
although I guess we need some backward compatibility mode?

> 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.



Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to