Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cchF9-00046l-62 for pgsql-general@arkaria.postgresql.org; Sat, 11 Feb 2017 23:38:15 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1cchF8-0003vm-PT for pgsql-general@arkaria.postgresql.org; Sat, 11 Feb 2017 23:38:14 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cchF8-0003vg-6W for pgsql-general@postgresql.org; Sat, 11 Feb 2017 23:38:14 +0000 Received: from out4-smtp.messagingengine.com ([66.111.4.28]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cchF5-0004vw-O3 for pgsql-general@postgresql.org; Sat, 11 Feb 2017 23:38:12 +0000 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 865D22064C; Sat, 11 Feb 2017 18:38:10 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Sat, 11 Feb 2017 18:38:10 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=aklaver.com; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=uCLeQp7T2lKO0d6 O8st2bTvDIvk=; b=UYRi4Nf1tTQSUTSGFacegOE471r08nqZlwaZ28SsMnhi5mI bGQDR7MNr1d+oZCiwKG4sqqIwTOdCr+OBIzK9VKyFV3CZJEXqHdOUViVcnn8hjYO kElQaUO0XkDpSkxGo2sXAmF5qgJDQwENLOtubBaH1mOwb8DQWWc+nnymu5hg= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=uCLeQp7T2lKO0d6O8st2bTvDIvk=; b=sa9sGyArOs1lPr9BtOz6 ilU4nQsEB8cV8MqrYDqL4NqMfqShp5Y/CDza6aCwhLjnlpfpLmkl0wu8VNmkzlkh UR0ClLeWYz3u2zkZcxp0qFhd+htpO6mwN9c5/177ZibYmeCFaoC24uuj5836fL0T oXRQDAf+38BvGHKq2+ZsOGo= X-ME-Sender: X-Sasl-enc: hQCAB/rmnEuRijItuQSi3dWYgUcWd2C8gvC81ZM/fG3b 1486856290 Received: from [192.168.1.2] (174-21-203-58.tukw.qwest.net [174.21.203.58]) by mail.messagingengine.com (Postfix) with ESMTPA id E68BD2453A; Sat, 11 Feb 2017 18:38:09 -0500 (EST) Subject: Re: intentional or oversight? pg_dump -c does not restore default priviliges on schema public To: Stephen Frost , Frank van Vugt References: <3534542.o3cNaKiDID@techfox> <20170211220617.GG9812@tamriel.snowman.net> Cc: pgsql-general@postgresql.org From: Adrian Klaver Message-ID: <9f29583d-4a82-55e7-619a-5a774dbabd8d@aklaver.com> Date: Sat, 11 Feb 2017 15:38:09 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <20170211220617.GG9812@tamriel.snowman.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -2.7 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-general Precedence: bulk Sender: pgsql-general-owner@postgresql.org On 02/11/2017 02:06 PM, Stephen Frost wrote: > Greetings, > > * Frank van Vugt (ftm.van.vugt@foxi.nl) wrote: >> I noticed the following and wondered whether this is intentional or an >> oversight in pg_dump's '-c' option? >> >> The clean option causes the public schema to be dropped and recreated, but >> this is done with the default schema priviliges, which are not the same as the >> ones assigned during create database: > > Interesting. The reason this happens is that the privileges for the > public schema aren't dumped when they are the same as what you would get > from a default install in 9.6+, but using -c will end up dropping and > recreating it, which, as you note, will end up having different > privileges than the default install because they'll be the regular > default privilegs of "nothing" for schemas. > > This is happening just for the public schema due to how it's handled in > a special way in pg_dump_archive.c:_printTocEntry(). This only impacts > ACLs because those are the only things which are different for the > public schema vs. it's initdb settings (there's no SECURITY LABEL, for > example, on the initdb'd public schema). > > Due to how the public schema is (and always has been) handled in this > special way, this is a bug which needs to be fixed by having the default > ACLs for the public schema included in the dump output if -c is being > used. I am following this up to the point of not understanding what exactly changed between 9.5 and 9.6. Namely 9.5 does include the default ACL's in the dump output and 9.6 does not. > > I'm not seeing a very simple answer for this, unfortunately. I'm > thinking we're going to need to pull the public schema's permissions > differently if we're in clean mode (by comparing to the default schema > privileges) vs. when we're not (in which case we should be comparing to > *public*'s initdb-time privileges, as we do now). One option would be > to handle that by hacking up buildACLQueries() to take a flag which > basically means "we are dropping the public schema, do not consider its > pg_init_privs settings" but that strikes me as awful grotty. Another > option would be to change getNamespaces() to run a special query > (perhaps as a UNION-ALL combination with the existing query) that is > just to get the info for the 'public' schema (and exclude the 'public' > schema from the first half of the query, of course). > > Thanks for the report! > > Stephen > -- Adrian Klaver adrian.klaver@aklaver.com -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general