Robert Haas <robertmhaas@gmail.com> writes:
> As far as I can see from reading the thread, most people agree that
> it's reasonable to have some way to disable ALTER SYSTEM, but there
> are at least six competing ideas about how to do that:
> 1. command-line option
> 2. GUC
> 3. event trigger
> 4. extension
> 5. sentinel file
> 6. remove permissions on postgresql.auto.conf
With the possible exception of #1, every one of these is easily
defeatable by an uncooperative superuser. I'm not excited about
adding a "security" feature with such obvious holes in it.
We reverted MAINTAIN last year for much less obvious holes;
how is it that we're going to look the other way on this one?
#2 with the GUC_DISALLOW_IN_AUTO_FILE flag can be made secure
(I think) by putting the main postgresql.conf file outside the
data directory and then making it not owned by or writable by the
postgres user. But I doubt that's a common configuration, and
I'm sure we will get complaints from people who failed to set it
up that way. The proposed patch certainly doesn't bother to
document the hazard.
Really we'd need to do something about removing superusers'
access to the filesystem in order to build something with
fewer holes. I'm not against inventing such a feature,
but it'd take a fair amount of work and likely would end
in a noticeably less usable system (no plpython for example).
regards, tom lane
