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