From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | Vik Fearing <vik(at)postgresfriends(dot)org> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Dump public schema ownership & seclabels |
Date: | 2021-02-11 12:08:34 |
Message-ID: | 20210211120834.GB746353@rfd.leadboat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Jan 17, 2021 at 12:00:06PM +0100, Vik Fearing wrote:
> On 1/17/21 10:41 AM, Noah Misch wrote:
> > On Sat, Jan 16, 2021 at 02:05:43PM +0100, Vik Fearing wrote:
> >> On 12/30/20 12:59 PM, Noah Misch wrote:
> >>> On Tue, Dec 29, 2020 at 05:49:24AM -0800, Noah Misch wrote:
> >>>> https://postgr.es/m/20201031163518.GB4039133@rfd.leadboat.com gave $SUBJECT as
> >>>> one of the constituent projects for changing the public schema default ACL.
> >>>> This ended up being simple. Attached.
> >>>
> >>> This is defective; it fails to reproduce nspacl after "ALTER SCHEMA public
> >>> OWNER TO pg_write_server_files; REVOKE ALL ON SCHEMA public FROM
> >>> pg_write_server_files;". I will try again later.
Fixed. The comment added to getNamespaces() explains what went wrong.
Incidentally, --no-acl is fragile without --no-owner, because any REVOKE
statements assume a particular owner. Since one can elect --no-owner at
restore time, we can't simply adjust the REVOKE statements constructed at dump
time. That's not new with this patch or specific to initdb-created objects.
> >> Could I ask you to also include COMMENTs when you try again, please?
> >
> > That may work. I had not expected to hear of a person changing the comment on
> > schema public. To what do you change it?
>
> It was a while ago and I don't remember because it didn't appear in the
> dump so I stopped doing it. :(
>
> Mine was an actual comment, but there are some tools out there that
> (ab)use COMMENTs as crude metadata for what they do. For example:
> https://postgresql-anonymizer.readthedocs.io/en/stable/declare_masking_rules/#declaring-rules-with-comments
I've attached a separate patch for this, which applies atop the ownership
patch. This makes more restores fail for non-superusers, which is okay.
Attachment | Content-Type | Size |
---|---|---|
public-owner-dump-v2.patch | text/plain | 19.8 KB |
public-schema-comment-dump-v1.patch | text/plain | 4.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Markus Wanner | 2021-02-11 12:16:49 | Re: repeated decoding of prepared transactions |
Previous Message | Amit Kapila | 2021-02-11 11:38:37 | Re: Single transaction in the tablesync worker? |