Re: [PATCH] Add reloption for views to enable RLS
Wolfgang Walther <walther@technowledgy.de>
From: walther@technowledgy.de
To: Laurenz Albe <laurenz.albe@cybertec.at>,
Christoph Heiss <christoph.heiss@cybertec.at>, pgsql-hackers@postgresql.org
Cc: Hans-Jürgen Schönig <hs@cybertec.at>
Date: 2022-02-15T15:07:56Z
Lists: pgsql-hackers
Laurenz Albe: >> 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 > "permissions_caller". 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. Best Wolfgang
Commits
-
Add support for security invoker views.
- 7faa5fc84bf4 15.0 landed
-
Replace use of deprecated Python module distutils.sysconfig
- e0e567a10672 15.0 cited