Re: pgsql: Revoke PUBLIC CREATE from public schema, now owned by pg_databas

From: Noah Misch <noah(at)leadboat(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pgsql: Revoke PUBLIC CREATE from public schema, now owned by pg_databas
Date: 2022-11-30 07:07:01
Message-ID: 20221130070701.GA275942@rfd.leadboat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

On Tue, Nov 29, 2022 at 02:22:59PM -0500, Robert Haas wrote:
> On Fri, Sep 10, 2021 at 2:39 AM Noah Misch <noah(at)leadboat(dot)com> wrote:
> > Revoke PUBLIC CREATE from public schema, now owned by pg_database_owner.
> >
> > This switches the default ACL to what the documentation has recommended
> > since CVE-2018-1058. Upgrades will carry forward any old ownership and
> > ACL. Sites that declined the 2018 recommendation should take a fresh
> > look. Recipes for commissioning a new database cluster from scratch may
> > need to create a schema, grant more privileges, etc. Out-of-tree test
> > suites may require such updates.
>
> I was looking at the changes that this commit made to ddl.sgml today
> and I feel that it's not quite ideal. Under "Constrain ordinary users
> to user-private schemas" it first says "To implement this, first issue
> <literal>REVOKE CREATE ON SCHEMA public FROM PUBLIC</literal>" and
> then later says, oh but wait, you actually don't need to do that
> unless you're upgrading. That seems a bit backwards to me: I think we
> should talk about the current state of play first, and then add the
> notes about upgrading afterwards.

In general, the documentation should prefer simpler decision trees.
Especially so where the wrong choice causes no error, yet leaves a security
vulnerability. The unconditional REVOKE has no drawbacks; it's harmless where
it's a no-op. That was the rationale behind the current text. Upgrades
aren't the only issue; another DBA may have changed the ACL since initdb.

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Alvaro Herrera 2022-11-30 11:08:26 pgsql: Stop accessing checkAsUser via RTE in some cases
Previous Message Michael Paquier 2022-11-30 05:47:15 pgsql: Add regression tests for psql's \o and \g on files

Browse pgsql-hackers by date

  From Date Subject
Next Message Drouvot, Bertrand 2022-11-30 07:13:14 Re: Introduce a new view for checkpointer related stats
Previous Message Peter Eisentraut 2022-11-30 07:04:01 pg_dump: Remove "blob" terminology