On Mon, Nov 2, 2015 at 10:17 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Stephen Frost <sfr...@snowman.net> writes: > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > >> How is it that we don't need rolcatupdate but we do need a way to shut > >> off ALTER SYSTEM? Doesn't compute, IMO. > > > I'd like the ability to control all of the above, ultimately. I don't > > believe that we should be allowing the superuser to always modify the > > catalog directly- and things like the sepgsql module can actually > > address that and limit when the superuser is allowed to with better > > granularity then what rolcatupdate provided (or was ever likely to > > provide, being a single boolean role attribute). > > Mumble. I have no objection to sepgsql deciding to disallow ALTER SYSTEM > --- after all, the entire point of that module is to enforce arbitrary > annoying restrictions ;-). But I am not convinced that we need any other > way to turn it off. As Robert points out, it's far *less* dangerous than > most other superuser-only features. > > Also, disallowing ALTER SYSTEM altogether strikes me as an extremely > brute-force solution to any of the specific issues you mention. If you're > worried about locking down shared_preload_libraries, for example, it would > be far better to lock down just that one variable. >
I think that is the sensible way to deal with this and any other such parameters. We already have a way to disallow setting of individual parameters (GUC_DISALLOW_IN_AUTO_FILE) via Alter System. Currently we disallow to set data_directory via this mechanism and I think we can do the same for other parameters if required. Do you think we should do some investigation/analysis about un-safe parameters rather then doing it in retail fashion? With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com