Re: 12 to 13 migration, the privs error with pg_pltemplate

From: Scott Ribe <scott_ribe(at)elevated-dev(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pgsql-admin <pgsql-admin(at)lists(dot)postgresql(dot)org>
Subject: Re: 12 to 13 migration, the privs error with pg_pltemplate
Date: 2020-12-11 21:04:34
Message-ID: F1D171AD-F02C-4D78-8152-11329B21E372@elevated-dev.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

> On Dec 11, 2020, at 1:36 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
>
> Yes, I specifically asked if you were looking at the correct database
> previously, because it matters:

At that time I thought I had run the original REVOKE command in the target database, and then tried ALTER DEFAULT PRIVILEGES in postgres. I was probably mistaken.

> I'm pretty sure none of this has anything to do with DEFAULT PRIVILEGES
> as those only actually apply when a new table is created (and not from a
> template database), and that's just never the case with any PG catalog
> tables.

So the fact that default privs were set on the system catalogs was inappropriate, but harmless in this case?

> What might be useful to point out is that only a superuser can change
> the privileges associated with PG catalog tables and that you really
> should be careful who you grant superuser privileges to.

Yes, that's one thing I took care of earlier this year: change our processes such that we were able to remove superuser from the commonly-used service accounts.

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Stephen Frost 2020-12-11 21:10:31 Re: 12 to 13 migration, the privs error with pg_pltemplate
Previous Message Stephen Frost 2020-12-11 20:36:34 Re: 12 to 13 migration, the privs error with pg_pltemplate