Re: ALTER SYSTEM vs symlink

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