Hi, On 2023-11-14 15:42:22 -0500, Tom Lane wrote: > Andres Freund <andres@xxxxxxxxxxx> 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
