Re: Add SECURITY_INVOKER_VIEWS option to CREATE DATABASE

From: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
To: Steve Chavez <steve(at)supabase(dot)io>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Add SECURITY_INVOKER_VIEWS option to CREATE DATABASE
Date: 2026-01-27 17:21:11
Message-ID: 1ad75ab82da82a6426c983ad652394226b350bbc.camel@cybertec.at
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 2026-01-27 at 11:36 -0500, Steve Chavez wrote:
> Currently views are not secure by default since they bypass RLS. PostgreSQL 15 introduced the
> `WITH (security_invoker = true)` option for this but it's easy to miss on every new view created.
>
> It's also inconsistent with functions, which default to SECURITY INVOKER.
>
> I propose adding an option: `CREATE DATABASE .. SECURITY_INVOKER_VIEWS <bool>` (false by default
> to maintain backwards compat), so a database will have newly created views as SECURITY INVOKER.
>
> Let me know what you think.

I don't like it.

First of all, such a setting won't guarantee that all views get created with "security_invoker"
set - the user is still free to explicitly set "security_invoker = off".

Second, and more importantly, that is a setting that changes the behavior of SQL statements,
which is something that the project has learned to fear. It is problematic if the same SQL
statement has different semantics with different settings. If somebody runs a DDL script in
a database created with SECURITY_INVOKER_VIEWS TRUE, it could happen that the resulting schema
causes unexpected "permission denied" errors in the application.

Yours,
Laurenz Albe

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jacob Champion 2026-01-27 17:36:11 Re: [oauth] Stabilize the libpq-oauth ABI (and allow alternative implementations?)
Previous Message Robert Haas 2026-01-27 17:11:23 Re: pgsql: Prevent invalidation of newly synced replication slots.