Re: security labels on databases are bad for dump & restore - Mailing list pgsql-hackers

From Andres Freund
Subject Re: security labels on databases are bad for dump & restore
Date
Msg-id 20150728191059.GF4726@alap3.anarazel.de
Whole thread Raw
In response to Re: security labels on databases are bad for dump & restore  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: security labels on databases are bad for dump & restore  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 2015-07-28 15:05:01 -0400, Robert Haas wrote:
> On Tue, Jul 28, 2015 at 3:03 PM, Andres Freund <andres@anarazel.de> wrote:
> > On 2015-07-28 14:58:26 -0400, Robert Haas wrote:
> >> Yes, I think we should make restoring the database's properties the
> >> job of pg_dump and remove it completely from pg_dumpall, unless we can
> >> find a case where that's really going to break things.
> >
> > CREATE DATABASE blarg;
> > SECURITY LABEL ON blarg IS 'noaccess';
> > ALTER DATABASE blarg SET default_tablespace = space_with_storage;
> > pg_restore
> > -> SECURITY LABEL ON blarg IS 'allow_access';
> > -> ALTER DATABASE blarg SET default_tablespace = space_without_storage;
> >
> > That's probably not sufficient reasons not to go that way, but I do
> > think there's a bunch more issues like that.
> 
> Could you use some complete sentences to describe what the actual
> issue is?  I can't make heads or tails of what you wrote there.

DBA creates a database and sets some properties (security labels, gucs,
acls) on it. Then goes on to restore a backup. Unfortunately that backup
might, or might not, overwrite the properties he configured depending on
whether the restored database already contains them and from which
version the backup originates.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Planner debug views
Next
From: Robert Haas
Date:
Subject: Re: security labels on databases are bad for dump & restore