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. Agreed Joe -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development
Description: OpenPGP digital signature