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