Alvaro,
> I think the only drawback of this is that there's no way to disable
> ALTER SYSTEM (i.e. there's no directory you can remove to prevent the
> thing from working). But is this a desirable property? I mean, if we
> want to disallow ALTER SYSTEM I think we should provide a direct way to
> do that, perhaps allow_alter_system = off in postgresql.conf; but I
> don't think we need to provide this, really, at least not in the first
> implementation.
Agreed that turning alter system off by deleting the directory is NOT a
desireable feature. I'm also unclear on the desire to disable ALTER
SYSTEM; if someone has superuser access, then they can just use
pg_write_file to add config directives anyway, no? So there's not any
security value in disabling it. Maybe there's a case I'm not thinking of.
Of course, people *can* disable it by creating a blank
postgresql.auto.conf file in the right place and making it
non-writeable, if they want.
We are missing one feature, which is the ability to relocate the
postgresql.auto.conf file if relocating it is desireable according to
some sysadmin spec. This kind of ties into another patch which was
discussed on this list -- the ability to relocate the recovery.conf
file. Personally, I think that it would be better for the users if we
provided a way to relocate *all* conf files to the same master
directory, but that we don't need a way to relocate each config file
individually, but that's a longer discussion.
In other words, let's accept an ALTER SYSTEM patch which doesn't support
relocating, and then argue whether a second patch which supports
relocating is needed.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
