Re: What's the point of allow_system_table_mods?

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: What's the point of allow_system_table_mods?
Date: 2019-05-10 18:06:12
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


On 2019-05-09 12:22:39 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > I'm not quite clear what the goal of allow_system_table_mods
> > is. Obviously, it's extremely dangerous to target catalogs with DDL. But
> > at the same time we allow DML to catalog tables without any sort of
> > restriction.
> The last is not true, see pg_class_aclmask().

You mean because it's restricted to superusers?

> > I also don't understand what's achieved by having
> > allow_system_table_mods be PGC_POSTMASTER.
> True. Possibly there was some confusion with ignore_system_indexes,
> which probably *should* be PGC_POSTMASTER: if you think the system
> indexes are corrupt then they're corrupt for everybody.

Hm, but it's pretty useful to be able to verify if system index
corruption is to blame, by enabling ignore_system_indexes in one
session. Don't really see us gaining anything by forcing it to be done

> > Wouldn't it be more sensible to disallow all catalog modifications
> > unless allow_system_table_mods was enabled, and make
> > allow_system_table_mods PGC_SUSET and GUC_DISALLOW_IN_FILE?
> I'm on board with the second part of that but not the first.
> DDL on the system catalogs is significantly more dangerous
> than DML, so I think that having an extra layer of protection
> for it is a good idea.

Why is it so much more dangerous? I've seen plenty of corrupted clusters
due to people doing DML against the catalogs. I'm OK with adding
separate GUCs for both, if we want to do that, but I do think we
shouldn't allow updating the catalogs wthout having having the superuser
explicitly opt into that. We need superusers permissions for a lot of
pretty routine tasks (say creating an extension with C functions) -
so that also being the permission to do dangerous things like UPDATE to
pg_class etc, isn't great.


Andres Freund

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2019-05-10 18:27:07 Re: Why is infinite_recurse test suddenly failing?
Previous Message Andres Freund 2019-05-10 17:51:41 Re: Inconsistency between table am callback and table function names