Re: SET variable - Permission issues

On Mon, Oct 10, 2011 at 1:06 PM, Joe Conway <mail(at)joeconway(dot)com> wrote:

> 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.
>

Even in a controlled environment, say in a company where only legit apps
developed in-house are run on the DB, a DBA would want peace of mind that
the developers are not setting these GUCs at runtime (which is often even
recommended in case of work_mem) to bypass a policy set by the DBA and are
capable of bringing the DB down to its knees.

Regards,
--
Gurjeet Singh
EnterpriseDB Corporation
The Enterprise PostgreSQL Company