Re: dumping database privileges broken in 9.6

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: dumping database privileges broken in 9.6
Date: 2016-06-29 15:50:17
Message-ID: 20160629155016.GP21416@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter,

* Peter Eisentraut (peter(dot)eisentraut(at)2ndquadrant(dot)com) 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.

Thanks!

Stephen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2016-06-29 16:01:29 Re: fixing consider_parallel for upper planner rels
Previous Message Robert Haas 2016-06-29 15:49:49 Re: bug in citext's upgrade script for parallel aggregates