From: | Wolfgang Walther <walther(at)technowledgy(dot)de> |
---|---|
To: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, Christoph Heiss <christoph(dot)heiss(at)cybertec(dot)at> |
Cc: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Hans-Jürgen Schönig <hs(at)cybertec(dot)at> |
Subject: | Re: [PATCH] Add reloption for views to enable RLS |
Date: | 2022-03-02 10:46:40 |
Message-ID: | e85af425-d4e2-63e6-1055-07664078eb98@technowledgy.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Dean Rasheed:
>> That is also the main reason I preferred naming it "security_invoker" -
>> it is consistent with other databases and eases transition from such
>> systems.
> [...]
>
> For my part, I find myself more and more convinced that
> "security_invoker" is the right name, because it matches the
> terminology used for functions, and in other database systems. I think
> the parallels between security invoker functions and security invoker
> views are quite strong.
>
> [...]
>
> When we come to write the release notes for this feature, saying that
> this version of PG now supports security invoker views is going to
> mean a lot more to people who already use that feature in other
> databases.
>
> What are other people's opinions?
All those points in favor of security_invoker are very good indeed. The
main objection was not the term invoker, though, but the implicit
association it creates as in "security_invoker=false behaves like
security definer". But this is clearly wrong, the "security definer"
semantics as used for functions or in other databases just don't apply
as the default in PG.
I think renaming the reloption was a shortcut to avoid that association,
while the best way to deal with that would be explicit documentation.
Meanwhile, the patch has added a mention about CURRENT_USER, so that's a
first step. Maybe an explicit mention that security_invoker=false, is
NOT the same as "security definer" and explaining why would already be
enough?
Best
Wolfgang
From | Date | Subject | |
---|---|---|---|
Next Message | Nitin Jadhav | 2022-03-02 11:15:20 | Re: Report checkpoint progress with pg_stat_progress_checkpoint (was: Report checkpoint progress in server logs) |
Previous Message | Amit Kapila | 2022-03-02 10:38:17 | Re: Design of pg_stat_subscription_workers vs pgstats |