On Mon, Nov 2, 2015 at 10:17 PM, Tom Lane <
tgl@sss.pgh.pa.us> wrote:
>
> Stephen Frost <
sfrost@snowman.net> writes:
> > * Tom Lane (
tgl@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?
