From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: ALTER SYSTEM vs symlink |
Date: | 2015-11-02 16:47:46 |
Message-ID: | 5076.1446482866@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2015-11-02 16:57:27 | Re: ALTER SYSTEM vs symlink |
Previous Message | Stephen Frost | 2015-11-02 16:39:45 | Re: ALTER SYSTEM vs symlink |