On Wed, Jul 06, 2022 at 09:10:53AM -0400, Bruce Momjian wrote:
> 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
I felt "previous behavior" was mildly ambiguous. I've changed it to "the
behavior of prior releases".
> databases" to "For existing databases". I think your big risk here is
Done. New version attached.
> 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?
No supported release has a wiki page link in its release notes. We used wiki
pages in the more-distant past, but I don't recall why. I am not aware of
wiki pages having relevant benefits.
Author: Noah Misch <n...@leadboat.com>
Commit: Noah Misch <n...@leadboat.com>
diff --git a/doc/src/sgml/release-15.sgml b/doc/src/sgml/release-15.sgml
index 179ad37..3ed986c 100644
--- a/doc/src/sgml/release-15.sgml
+++ b/doc/src/sgml/release-15.sgml
@@ -58,16 +58,17 @@ Author: Noah Misch <n...@leadboat.com>
</para>
<para>
- This is a change in the default for newly-created databases in
- existing clusters and for new clusters; <literal>USAGE</literal>
- permissions on the <literal>public</literal> schema has not
- been changed. Databases restored from previous Postgres releases
- will be restored with their current permissions. Users wishing
- to have the former permissions will need to grant
- <literal>CREATE</literal> permission for <literal>PUBLIC</literal>
- on the <literal>public</literal> schema; this change can be made
- on <literal>template1</literal> to cause all new databases
- to have these permissions.
+ 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 <literal>REVOKE</literal> to adopt this new
+ default. For a new database having zero need to defend against insider
+ threats, granting back the privilege yields the behavior of prior
+ releases. (<literal>USAGE</literal> permission on this schema has not
+ changed.)
</para>
</listitem>
