Re: SET variable - Permission issues - Mailing list pgsql-hackers

From Joe Conway
Subject Re: SET variable - Permission issues
Date
Msg-id 4E9325FA.1050907@joeconway.com
Whole thread Raw
In response to Re: SET variable - Permission issues  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: SET variable - Permission issues
List pgsql-hackers
On 10/09/2011 09:09 PM, Robert Haas wrote:
> Having said that, I do think it might be useful to have ways of
> controlling the values that users can set for GUC values, not so much
> as a guard against an all-out assault (which is probably futile) but
> as a way for DBAs to enforce system policy.  But even that seems like
> a lot of work for a fairly marginal benefit....

I think the issues Josh raised are valid concerns for a number of use
cases. Even if you don't want to allow anyone on the Internet into your
database (as Josh does, since his application is a game and his attempt
is to set policies and privileges such that it is actually safe), there
are plenty of companies needing to run Postgres in a multi-tenant
environment.

Currently customer A canset work_mem = <some very large number>;
andset statement_timeout = 0;
and run a big query effectively DOS'ing customers B, C, and D. If these
two settings could be restricted by the DBA, there would be a much lower
chance of this happening. There are undoubtedly other holes to fill, but
it seems like a worthy cause.

Joe

-- 
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Training, Service, Consulting, & 24x7 Support


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: WIP: Join push-down for foreign tables
Next
From: Florian Pflug
Date:
Subject: Re: Range Types - typo + NULL string constructor