Re: What's the point of allow_system_table_mods?

Hi,

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
system-wide.

> > 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.

Greetings,

Andres Freund