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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers