Re: security labels on databases are bad for dump & restore

From: Noah Misch <noah(at)leadboat(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Adam Brightwell <adam(dot)brightwell(at)crunchydatasolutions(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>
Subject: Re: security labels on databases are bad for dump & restore
Date: 2015-07-29 04:39:27
Message-ID: 20150729043927.GA1573621@tornado.leadboat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jul 28, 2015 at 03:36:13PM -0400, Robert Haas wrote:
> On Tue, Jul 28, 2015 at 3:33 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> > Hm? Let me try again: If the admin does a ALTER DATABASE ... SET guc =
> > ... *before* restoring a backup and the backup does contain a setting
> > for the same guc, but with a different value it'll overwrite the
> > previous explicit action by the DBA without any warning. If the backup
> > does *not* contain that guc the previous action survives. That's
> > confusing, because you're more likely to be in the 'the backup does not
> > contain the guc' situation when testing where it thus will work.
>
> True. But I don't think modifying a database before restoring into it
> is terribly supported. Even pg_dump --clean, which is supposed to do
> this sort of thing, doesn't seem to work terribly reliably. We could
> try to fix this by having a command like ALTER DATABASE ... RESET ALL
> that we issue before restoring the settings, but I'm afraid that will
> take us into all sorts of unreasonable scenarios that are better just
> labeled as "don't do that".

Andres's example is a harbinger of the semantic morass ahead. Excepting
database objects and the "public" schema object, pg_dump and pg_dumpall mutate
only the objects they CREATE. They consistently restore object properties
(owner, ACLs, security label, etc.) if and only if issuing a CREATE statement
for the object. For example, restoring objects contained in a schema without
restoring the schema itself changes none of those schema properties. pg_dump
and pg_dumpall have mostly followed that rule for databases, too, but they
depart from it for comment and security label. That was a mistake. We can't
in general mutate an existing database to match, because we can't mutate the
encoding, datcollate or datctype. Even discounting that problem, I value
consistency with the rest of the dumpable object types.

I suppose many folks using pg_dump without --create think of it as a dump of a
database itself, not a dump of a database's contents. They would benefit from
a dump that mutates the target database to match the properties of the source
database. Helping those folks does not offset the aforementioned losses.

Thanks,
nm

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2015-07-29 07:13:42 Re: Supporting TAP tests with MSVC and Windows
Previous Message Joe Conway 2015-07-29 04:02:18 Re: more RLS oversights