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
