Re: dumping database privileges broken in 9.6

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: dumping database privileges broken in 9.6
Date: 2016-07-02 19:03:01
Message-ID: CAOuzzgrb36pcx-JiW7LxRg_6F7Je3rRfkg55Q6jkDb=_U0eMWg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Noah, all,

On Saturday, July 2, 2016, Noah Misch <noah(at)leadboat(dot)com> wrote:

> On Wed, Jun 29, 2016 at 11:50:17AM -0400, Stephen Frost wrote:
> > * Peter Eisentraut (peter(dot)eisentraut(at)2ndquadrant(dot)com <javascript:;>)
> wrote:
> > > Do this:
> > >
> > > CREATE DATABASE test1;
> > > REVOKE CONNECT ON DATABASE test1 FROM PUBLIC;
> > >
> > > Run pg_dumpall.
> > >
> > > In 9.5, this produces
> > >
> > > CREATE DATABASE test1 WITH TEMPLATE = template0 OWNER = peter;
> > > REVOKE ALL ON DATABASE test1 FROM PUBLIC;
> > > REVOKE ALL ON DATABASE test1 FROM peter;
> > > GRANT ALL ON DATABASE test1 TO peter;
> > > GRANT TEMPORARY ON DATABASE test1 TO PUBLIC;
> > >
> > > In 9.6, this produces only
> > >
> > > CREATE DATABASE test1 WITH TEMPLATE = template0 OWNER = peter;
> > > GRANT TEMPORARY ON DATABASE test1 TO PUBLIC;
> > > GRANT ALL ON DATABASE test1 TO peter;
> > >
> > > Note that the REVOKE statements are missing. This does not
> > > correctly recreate the original state.
> >
> > I see what happened here, the query in dumpCreateDB() needs to be
> > adjusted to pull the default information to then pass to
> > buildACLComments(), similar to how the objects handled by pg_dump work.
> > The oversight was in thinking that databases didn't have any default
> > rights granted, which clearly isn't correct.
> >
> > I'll take care of that in the next day or so and add an appropriate
> > regression test.
>
> This PostgreSQL 9.6 open item is past due for your status update. Kindly
> send
> a status update within 24 hours, and include a date for your subsequent
> status
> update. Refer to the policy on open item ownership:
>
> http://www.postgresql.org/message-id/20160527025039.GA447393@tornado.leadboat.com
>

Will work on it tomorrow but for a deadline for next status update, I'll
say Tuesday (which I expect is when I'll commit the fix) as it's a holiday
weekend in the US.

Thanks!

Stephen

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2016-07-02 19:20:13 Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <
Previous Message Noah Misch 2016-07-02 18:29:34 Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <