From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Aditya D <dsaditya91(at)gmail(dot)com>, pgsql-admin <pgsql-admin(at)lists(dot)postgresql(dot)org> |
Subject: | Re: pg_restore -L reordering of the statements does not work |
Date: | 2023-11-14 22:27:43 |
Message-ID: | 20231114222743.x2c2r74ttgom2cfx@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
Hi,
On 2023-11-14 15:42:22 -0500, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2023-11-14 22:40:02 | Re: pg_restore -L reordering of the statements does not work |
Previous Message | Tom Lane | 2023-11-14 20:42:22 | Re: pg_restore -L reordering of the statements does not work |