Re: First draft of the PG 15 release notes - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: First draft of the PG 15 release notes
Date
Msg-id YsWJ3XYbT7qMfpmy@momjian.us
Whole thread Raw
In response to Re: First draft of the PG 15 release notes  (Noah Misch <noah@leadboat.com>)
Responses Re: First draft of the PG 15 release notes
List pgsql-hackers
On Tue, Jul  5, 2022 at 07:45:57PM -0700, Noah Misch wrote:
> On Tue, Jul 05, 2022 at 07:47:52PM -0400, Bruce Momjian wrote:
> > Yes, I think it is a question of practicality vs. desirability.  We are
> > basically telling people they have to do research to get the old
> > behavior in their new databases and clusters.
> 
> True.  I want to maximize the experience for different classes of database:
> 
> 1. Databases needing user isolation and unknowingly not getting it.
> 2. Databases not needing user isolation, e.g. automated test environments.
> 
> Expecting all of these DBAs to read a 500-word doc section is failure-prone.
> For the benefit of (2), I'm now thinking about adding a release note sentence,
> "For a new database having zero need to defend against insider threats,
> granting back the privilege yields the PostgreSQL 14 behavior."

I think you would need to say "previous behavior" since people might be
upgrading from releases before PG 14.  I also would change "In existing
databases" to "For existing databases".  I think your big risk here is
trying to explain how to have new clusters get the old or new behavior
in the same text block, e.g.:

     The new default is one of the secure schema usage patterns that
     <xref linkend="ddl-schemas-patterns"/> has recommended since the
     security release for CVE-2018-1058.  Upgrading a cluster or restoring a
     database dump will preserve existing permissions.  This is a change in
     the default for newly-created databases in existing clusters and for new
     clusters.  For existing databases, especially those having multiple
     users, consider issuing a <literal>REVOKE</literal> to adopt this new
     default.  (<literal>USAGE</literal> permission on this schema has not
     changed.)  For a new database having zero need to defend against insider
     threats, granting back the privilege yields the previous behavior.

Is this something we want to get into in the release notes, or perhaps
do we need to link to a wiki page for these details?

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Indecision is a decision.  Inaction is an action.  Mark Batterson




pgsql-hackers by date:

Previous
From: Maxim Orlov
Date:
Subject: Re: Fix unnecessary includes and comments in 019_replslot_limit.pl, 007_wal.pl and 004_timeline_switch.pl
Next
From: Andres Freund
Date:
Subject: Re: [RFC] building postgres with meson -v9