From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: First draft of the PG 15 release notes |
Date: | 2022-07-05 21:57:52 |
Message-ID: | 20220705215752.GC2648447@rfd.leadboat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jul 05, 2022 at 04:35:32PM -0400, Bruce Momjian wrote:
> On Tue, Jul 5, 2022 at 12:53:49PM -0700, Noah Misch wrote:
> > On Tue, Jul 05, 2022 at 02:35:39PM -0400, Bruce Momjian wrote:
> > > On Fri, Jul 1, 2022 at 06:21:28PM -0700, Noah Misch wrote:
> > > > Here's what I've been trying to ask: what do you think of linking to
> > > > https://www.postgresql.org/docs/devel/ddl-schemas.html#DDL-SCHEMAS-PATTERNS
> > > > here? The release note text is still vague, and the docs have extensive
> > > > coverage of the topic. The notes can just link to that extensive coverage.
> > >
> > > Sure. how is this patch?
> >
> > > --- a/doc/src/sgml/release-15.sgml
> > > +++ b/doc/src/sgml/release-15.sgml
> > > @@ -63,11 +63,12 @@ Author: Noah Misch <noah(at)leadboat(dot)com>
> > > 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
> > > + to have the former more-open 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.
> > > + to have these permissions. This change was made to increase
> > > + security; see <xref linkend="ddl-schemas-patterns"/>.
> > > </para>
> > > </listitem>
> >
> > I think this still puts undue weight on single-user systems moving back to the
> > old default. The linked documentation does say how to get back to v14
> > permissions (and disclaims security if you do so), so let's not mention it
> > here. The attached is how I would write it. I also reworked the "Databases
> > restored from previous ..." sentence, since its statement is also true of
> > databases restored v15-to-v15 (no "previous" release involved). I also moved
> > the bit about USAGE to end, since it's just emphasizing what the reader should
> > already assume. Any concerns?
>
> I see where you are going --- to talk about how to convert upgraded
> clusters to secure clusters, rather than how to revert to the previous
> behavior. I assumed that the most common question would be how to get
> the previous behavior, rather than how to get the new behavior in
> upgraded clusters. However, I am fine with what you think is best.
Since having too-permissive ACLs is usually symptom-free, I share your
forecast about the more-common question. Expect questions on mailing lists,
stackoverflow, etc. The right way to answer those questions is roughly this:
> On PostgreSQL 15, my application gets "permission denied for schema
> public". What should I do?
You have a choice to make. The best selection depends on the security
needs of your database. See
https://www.postgresql.org/docs/devel/ddl-schemas.html#DDL-SCHEMAS-PATTERNS
for a guide to making that choice.
Recommending GRANT to that two-sentence question would be negligent. One
should know a database's lack of security needs before recommending GRANT.
This is a key opportunity to have more users make the right decision while
their attention is on the topic.
> My only stylistic suggestion would be to remove "a" from "a
> <literal>REVOKE</literal>".
I'll plan to push with that change.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2022-07-05 22:05:07 | Re: [UNVERIFIED SENDER] Re: pg_upgrade can result in early wraparound on databases with high transaction load |
Previous Message | Andres Freund | 2022-07-05 21:52:45 | Re: Issue with pg_stat_subscription_stats |