pg.ddx.io  pgsql-admin@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Aditya D <dsaditya91@gmail.com>
Cc: pgsql-admin <pgsql-admin@lists.postgresql.org>
Subject: Re: pg_restore -L reordering of the statements does not work
Date: Tue, 14 Nov 2023 14:27:43 -0800
Message-ID: <20231114222743.x2c2r74ttgom2cfx@awork3.anarazel.de> (raw)
In-Reply-To: <2522830.1699994542@sss.pgh.pa.us>
References: <CAEATte6vgZr6d2abZo9_wxTarwQP3TC_NLpCKTDzWW4E4OB9cw@mail.gmail.com>
	<1589825.1698431686@sss.pgh.pa.us>
	<20231114194933.ci3nxol3avtisyrs@awork3.anarazel.de>
	<2522830.1699994542@sss.pgh.pa.us>

Hi,

On 2023-11-14 15:42:22 -0500, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > A schema like:
> > ...
> > results in the following, abbreviated, dump on HEAD:
> > ...
> > Which is bad because the ALTER TABLE OWNER TO cannot be executed before
> > the GRANT ALL:
> >   ERROR:  42501: permission denied for schema nosuper
> >   LOCATION:  aclcheck_error, aclchk.c:2833
> 
> Works fine for me.  I agree that it might not work if you're restoring
> as non-superuser, but if you try that the ALTER OWNER commands are all
> going to fail too.

It's indeed dependent on restoring as a non-superuser. Notably even if
restoring as nosuper_1.


> Moreover, reordering the GRANTs is no solution, because who promised that
> the schema owner granted you any permissions?

I'm not quite following - the schema is created in the dump, so the grant is
part of it?


> The bigger picture here is that pg_dump effectively relies on all
> objects being treated throughout the restore as though the restoring
> user is their owner --- either via --no-owner, or because the
> restoring user is superuser, or perhaps because the restoring user is
> a member of every object owner named in the dump.

In my repro I was restoring with nosuper_1, which is granted membership to
nosuper_2.


> Postponing execution of GRANTs to the end should therefore be perfectly
> safe, and indeed it's *necessary* if you want to successfully restore cases
> in which an object owner has revoked some of their own privileges.
> 
> I experimented with making the restoring user be a member with inherit
> of the nosuper_N roles, and indeed I still see the failure above,
> which makes me wonder if the ACL check is being done correctly for
> that specific case.  The INHERIT bit ought to let it work.

The check is for nosuper_2 to have permission on the schema and the check
happens before the grant on the schema. For inherit to help, nosuper_2 would
have to be granted membership to the presumably more privileged user doing the
restore.

Greetings,

Andres Freund





view thread (14+ messages)  latest in thread

Message-ID: <20231114222743.x2c2r74ttgom2cfx@awork3.anarazel.de>
Permalink:  ../20231114222743.x2c2r74ttgom2cfx@awork3.anarazel.de/
Also on:    postgresql.org/message-id/20231114222743.x2c2r74ttgom2cfx@awork3.anarazel.de

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-admin@postgresql.org
  Cc: andres@anarazel.de, tgl@sss.pgh.pa.us, dsaditya91@gmail.com, pgsql-admin@lists.postgresql.org
  Subject: Re: pg_restore -L reordering of the statements does not work
  In-Reply-To: <20231114222743.x2c2r74ttgom2cfx@awork3.anarazel.de>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox