On 10/10/2011 01:52 PM, Gurjeet Singh wrote: >On Mon, Oct 10, 2011 at 2:38 PM, Tom Lane wrote: >> Any developer who can't think of six ways to DOS the server without >> changing those settings should be fired on the spot for incompetence.
Perhaps, but I think our long term goal at least should be to make it possible to prevent that -- not necessarily the default configuration, but it should be at least *possible* for a sufficiently careful DBA to harden their postgres instance. I have multiple clients that either do run or would like to run postgres multi-tenant, and at the moment that is somewhere between risky and unacceptable. > Would it be possible to make the SUSET/USERSET property of a GUC > modifiable? So a DBA can do > > ALTER USER novice SET CONTEXT OF work_mem TO 'superuser'; > > Or, maybe > > ALTER USER novice SET MAX_VAL OF work_mem TO '1 MB'; > > and extend it to say > > ALTER USER novice SET MIN_VAL OF statement_timeout TO '1'; > -- So that the user cannot turn off the timeout > > ALTER DATABASE super_reliable SET ENUM_VALS OF synchronous_commit TO 'on'; > -- So that the user cannot change the synchronicity of transactions > against this database. I like this better than GRANT/REVOKE on SET. Joe -- Joe Conway credativ LLC: http://www.credativ.us Linux, PostgreSQL, and general Open Source Training, Service, Consulting, & 24x7 Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
