Re: public schema default ACL
Noah Misch <noah@leadboat.com>
From: Noah Misch <noah@leadboat.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, "David G. Johnston" <david.g.johnston@gmail.com>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Stephen Frost <sfrost@snowman.net>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2020-10-18T12:51:47Z
Lists: pgsql-hackers
On Wed, Aug 05, 2020 at 10:00:02PM -0700, Noah Misch wrote: > On Mon, Aug 03, 2020 at 09:46:23AM -0400, Robert Haas wrote: > > On Mon, Aug 3, 2020 at 2:30 AM Noah Misch <noah@leadboat.com> wrote: > > > Between (b)(2)(X) and (b)(3)(X), what are folks' preferences? Does anyone > > > strongly favor some other option (including the option of changing nothing) > > > over both of those two? > > > > I don't think we have any options here that are secure but do not > > break backward compatibility. > > I agree, but compatibility breaks vary in pain caused. I want to offer a > simple exit to a backward-compatible configuration, and I want a $NEW_DEFAULT > pleasing enough that a decent fraction of deployments keep $NEW_DEFAULT (forgo > the exit). The move to default standard_conforming_strings=on is an example > to follow (editing postgresql.conf was the simple exit). > > > I don't know how to choose between (1), (2), and (3). > > One way is to envision deployments you know and think about a couple of > questions in the context of those deployments. If $EACH_OPTION happened, > would this deployment keep $NEW_DEFAULT, override $NEW_DEFAULT to some other > secure configuration, or exit to $v13_DEFAULT? Where the answer is "exit", > would those deployments rate the exit recipe easy, medium, or difficult? It sounds like you might prefer to wait for better ideas and not change $SUBJECT for now. Is that right?
Commits
-
Revoke PUBLIC CREATE from public schema, now owned by pg_database_owner.
- b073c3ccd06e 15.0 landed
-
Document security implications of search_path and the public schema.
- 5770172cb0c9 11.0 cited