Horton

Re: public schema default ACL

Noah Misch <noah@leadboat.com>

View thread View on postgr.es
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-08-06T05:00:02Z
Lists: pgsql-hackers 
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?

Commits

  1. Revoke PUBLIC CREATE from public schema, now owned by pg_database_owner.

  2. Document security implications of search_path and the public schema.