Hi, On 2019-05-09 12:22:39 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.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
