Re: allow_system_table_mods stuff

On 2019-06-21 11:12:38 +0200, Peter Eisentraut wrote:
> After the earlier thread [0] that dealt with ALTER TABLE on system
> catalogs, I took a closer look at the allow_system_table_mods setting.
> I found a few oddities, and it seems there is some room for improvement.

I complained about this recently again, and unfortunately the reaction
wasn't that welcoming:
https://postgr.es/m/20190509145054.byiwa255xvdbfh3a%40alap3.anarazel.de

> Attached are some patches to get the discussion rolling: One patch makes
> allow_system_table_mods settable at run time by superuser

+1 - this seems to have agreement.

> - For the most part, a_s_t_m establishes an additional level of access
> control on top of superuserdom for doing DDL on system catalogs. That
> seems like a useful definition.
>
> - But enabling a_s_t_m also allows a non-superuser to do DML on system
> catalogs. That seems like an entirely unrelated and surprising behavior.

Indeed.

> - Some checks are redundant with the pinning concept of the dependency
> system. For example, you can't drop a system catalog even with a_s_t_m
> on. That seems useful, of course, but as a result there is a bit of
> dead or useless code around. (The dependency system is newer than a_s_t_m.)

I'm not fond of deduplicating things around this. This seems like a
separate layers of defense to me.

> - Having a test suite like this seems useful.

+1

> - The behavior that a_s_t_m allows non-superusers to do DML on system
> catalogs should be removed. (Regular permissions can be used for that.)

+1

> - Dead code or code that is redundant with pinning should be removed.

-1

> Any other thoughts?

* a_s_t_m=off should forbid modifying catalog tables, even for
superusers.

Greetings,

Andres Freund