* Haribabu Kommi (kommi.harib...@gmail.com) wrote: > On Fri, Oct 9, 2015 at 2:04 PM, Stephen Frost <sfr...@snowman.net> 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 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 changed in function check_enable_rls to use the invoker id instead of owner > id > for all the system objects, the catalog table policies are getting > applied and it is > working fine till now in my multi-tenancy testing. > > Currently I am writing tests to validate it against all user objects also. > If this change works for all user objects also, then we may not needed > the security invoker > reloption.
The reloption would be to allow the user to decide which behavior they wanted, as there are use-cases for both. Thanks! Stephen
signature.asc
Description: Digital signature
