From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Josh <josh(at)schemaverse(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: SET variable - Permission issues |
Date: | 2011-10-10 17:06:02 |
Message-ID: | 4E9325FA.1050907@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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 can
set work_mem = <some very large number>;
and
set 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
From | Date | Subject | |
---|---|---|---|
Next Message | Florian Pflug | 2011-10-10 17:22:50 | Re: Range Types - typo + NULL string constructor |
Previous Message | Tom Lane | 2011-10-10 16:58:51 | Re: WIP: Join push-down for foreign tables |