|To:||Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Christoph Heiss <christoph(dot)heiss(at)cybertec(dot)at>, pgsql-hackers(at)postgresql(dot)org|
|Cc:||Hans-Jürgen Schönig <hs(at)cybertec(dot)at>|
|Subject:||Re: [PATCH] Add reloption for views to enable RLS|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
>> I converted the option to run_as_owner=true|false in the attached v7.
>> It now definitely seems like the right way to move forward and getting
>> more feedback.
> I think we are straying from the target.
> "run_as_owner" seems wrong to me, because it is all about permission
> checking and*not* about running. As we have established, the query
> is always executed by the caller.
> So my preferred bikeshed colors would be "permissions_owner" or
My main point was the "xxx_owner = true by default" thing. Whether xxx
is "permissions" or "run_as" doesn't change that. permissions_caller,
however, would be a step backwards.
I can see how permissions_owner is better than run_as_owner. The code
uses checkAsUser, so check_as_owner would be an option, too. Although
that could easily be associated with WITH CHECK OPTION. Thinking about
that, the difference between LOCAL and CASCADED for CHECK OPTION pretty
much sums up one of the confusing bits about the whole thing, too.
Maybe "local_permissions_owner = true | false"? That would make it
crystal-clear, that this is only about the very first permissions check
and not about any checks later in a chain of multiple views.
"local_permissions = owner | caller" could also work - as long as we're
not using any of definer or invoker.
|Next Message||Andrew Dunstan||2022-02-15 15:12:35||Re: fairywren is generating bogus BASE_BACKUP commands|
|Previous Message||Ashutosh Sharma||2022-02-15 15:06:48||Re: Identify missing publications from publisher while create/alter subscription.|