> On Dec 11, 2020, at 1:36 PM, Stephen Frost <sfrost@snowman.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
PRIVILEGESin 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
fromthe commonly-used service accounts.
