On Mon, Nov 2, 2015 at 10:40 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Mon, Nov 2, 2015 at 10:13 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: >>> 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? > >> -1. > >> This was discussed before, and I feel about it now the same way I felt >> about it then: disallowing all GUCs that could potentially cause the >> server not to start would make ALTER SYSTEM a whole lot less useful. > > I definitely agree that unconditionally disallowing "unsafe" parameters > in ALTER SYSTEM would be counterproductive. data_directory is disallowed > there only because it's nonsensical: you can't even find the auto.conf > file until you've settled on the data_directory. > > However, where I thought this discussion was going was to allow admins > to selectively disable particular parameters from being set that way. > Whether a particular installation finds locking down > shared_preload_libraries to be more useful than allowing it to be set > doesn't seem to me to be a one-size-fits-all question. So at least in > principle I'd be okay with a feature to control that. But maybe it's > sufficient to say "you can use sepgsql to restrict that". Not every > feature needs to be in core.
I really think this is a fine use of a custom contrib module. If it's important, we can even include that contrib module in the core distribution as an example of how to restrict access to specific commands or subcommands that a user may want to prevent in their environment. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
