| From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
|---|---|
| To: | Steve Chavez <steve(at)supabase(dot)io> |
| Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Add SECURITY_INVOKER_VIEWS option to CREATE DATABASE |
| Date: | 2026-01-29 06:25:10 |
| Message-ID: | b23008d0a7ef0081b81a1584cfafd11965f806a0.camel@cybertec.at |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, 2026-01-28 at 15:43 -0500, Steve Chavez wrote:
> But that is a property of just regular views not necessarily security_barrier right? i.e. "to be able to hide certain columns".
Right, but without "security_barries = on" it may be that a sneaky attacker
can subvert the security. With that setting, only LEAKPROOF functions and
operators are can be pushed into the view definition.
But we are getting off-topic. My point is that your proposed database setting
would change the behavior of such a view so that it wouldn't work any more.
Yours,
Laurenz Albe
| From | Date | Subject | |
|---|---|---|---|
| Next Message | cca5507 | 2026-01-29 06:29:05 | Re: Fix logical decoding not track transaction during SNAPBUILD_BUILDING_SNAPSHOT |
| Previous Message | Corey Huinker | 2026-01-29 06:20:10 | Re: Extended Statistics set/restore/clear functions. |