Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit e961341

Browse files
committed
pg_dump: Properly handle public schema ACLs with --clean
pg_dump has always handled the public schema in a special way when it comes to the "--clean" option. To wit, we do not drop or recreate the public schema in "normal" mode, but when we are run in "--clean" mode then we do drop and recreate the public schema. When running in "--clean" mode, the public schema is dropped and then recreated and it is recreated with the normal schema-default privileges of "nothing". This is unlike how the public schema starts life, which is to have CREATE and USAGE GRANT'd to the PUBLIC role, and that is what is recorded in pg_init_privs. Due to this, in "--clean" mode, pg_dump would mistakenly only dump out the set of privileges required to go from the initdb-time privileges on the public schema to whatever the current-state privileges are. If the privileges were not changed from initdb time, then no privileges would be dumped out for the public schema, but with the schema being dropped and recreated, the result was that the public schema would have no ACLs on it instead of what it should have, which is the initdb-time privileges. Practically speaking, this meant that pg_dump with --clean mode dumping a database where the ACLs on the public schema were not changed from the default would, upon restore, result in a public schema with *no* privileges GRANT'd, not matching the state of the existing database (where the initdb-time privileges would have been CREATE and USAGE to the PUBLIC role for the public schema). To fix, adjust the query in getNamespaces() to ignore the pg_init_privs entry for the public schema when running in "--clean" mode, meaning that the privileges for the public schema would be dumped, correctly, as if it was going from a newly-created schema to the current state (which is, indeed, what will happen during the restore thanks to the DROP/CREATE). Only the public schema is handled in this special way by pg_dump, no other initdb-time objects are dropped/recreated in --clean mode. Back-patch to 9.6 where the bug was introduced. Discussion: https://postgr.es/m/3534542.o3cNaKiDID%40techfox
1 parent 8ea8178 commit e961341

File tree

2 files changed

+45
-3
lines changed

2 files changed

+45
-3
lines changed

src/bin/pg_dump/pg_dump.c

+21-1
Original file line numberDiff line numberDiff line change
@@ -3638,13 +3638,33 @@ getNamespaces(Archive *fout, int *numNamespaces)
36383638
"LEFT JOIN pg_init_privs pip "
36393639
"ON (n.oid = pip.objoid "
36403640
"AND pip.classoid = 'pg_namespace'::regclass "
3641-
"AND pip.objsubid = 0) ",
3641+
"AND pip.objsubid = 0",
36423642
username_subquery,
36433643
acl_subquery->data,
36443644
racl_subquery->data,
36453645
init_acl_subquery->data,
36463646
init_racl_subquery->data);
36473647

3648+
/*
3649+
* When we are doing a 'clean' run, we will be dropping and recreating
3650+
* the 'public' schema (the only object which has that kind of
3651+
* treatment in the backend and which has an entry in pg_init_privs)
3652+
* and therefore we should not consider any initial privileges in
3653+
* pg_init_privs in that case.
3654+
*
3655+
* See pg_backup_archiver.c:_printTocEntry() for the details on why
3656+
* the public schema is special in this regard.
3657+
*
3658+
* Note that if the public schema is dropped and re-created, this is
3659+
* essentially a no-op because the new public schema won't have an
3660+
* entry in pg_init_privs anyway, as the entry will be removed when
3661+
* the public schema is dropped.
3662+
*/
3663+
if (dopt->outputClean)
3664+
appendPQExpBuffer(query," AND pip.objoid <> 'public'::regnamespace");
3665+
3666+
appendPQExpBuffer(query,") ");
3667+
36483668
destroyPQExpBuffer(acl_subquery);
36493669
destroyPQExpBuffer(racl_subquery);
36503670
destroyPQExpBuffer(init_acl_subquery);

src/bin/pg_dump/t/002_pg_dump.pl

+24-2
Original file line numberDiff line numberDiff line change
@@ -2443,6 +2443,28 @@
24432443
only_dump_test_schema => 1,
24442444
only_dump_test_table => 1,
24452445
test_schema_plus_blobs => 1, }, },
2446+
'GRANT USAGE ON SCHEMA public TO public' => {
2447+
regexp => qr/^
2448+
\Q--\E\n\n
2449+
\QGRANT USAGE ON SCHEMA public TO PUBLIC;\E
2450+
/xm,
2451+
like => {
2452+
clean => 1,
2453+
clean_if_exists => 1, },
2454+
unlike => {
2455+
binary_upgrade => 1,
2456+
createdb => 1,
2457+
defaults => 1,
2458+
exclude_dump_test_schema => 1,
2459+
exclude_test_table => 1,
2460+
exclude_test_table_data => 1,
2461+
no_owner => 1,
2462+
pg_dumpall_dbprivs => 1,
2463+
schema_only => 1,
2464+
section_pre_data => 1,
2465+
only_dump_test_schema => 1,
2466+
only_dump_test_table => 1,
2467+
test_schema_plus_blobs => 1, }, },
24462468
'GRANT commands' => { # catch-all for GRANT commands
24472469
regexp => qr/^GRANT /m,
24482470
like => {}, # use more-specific options above
@@ -2576,8 +2598,6 @@
25762598
/xm,
25772599
like => {
25782600
binary_upgrade => 1,
2579-
clean => 1,
2580-
clean_if_exists => 1,
25812601
createdb => 1,
25822602
defaults => 1,
25832603
exclude_dump_test_schema => 1,
@@ -2588,6 +2608,8 @@
25882608
schema_only => 1,
25892609
section_pre_data => 1, },
25902610
unlike => {
2611+
clean => 1,
2612+
clean_if_exists => 1,
25912613
only_dump_test_schema => 1,
25922614
only_dump_test_table => 1,
25932615
test_schema_plus_blobs => 1, }, },

0 commit comments

Comments
 (0)