Re: SET variable - Permission issues
От | Gurjeet Singh |
---|---|
Тема | Re: SET variable - Permission issues |
Дата | |
Msg-id | CABwTF4VwmVuqSz9s1648KbzmH8ONe0qF1oFEtDvn-HxoMCLnNQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: SET variable - Permission issues (Joe Conway <mail@joeconway.com>) |
Ответы |
Re: SET variable - Permission issues
|
Список | pgsql-hackers |
On Mon, Oct 10, 2011 at 1:06 PM, Joe Conway <mail@joeconway.com> wrote:
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.
On 10/09/2011 09:09 PM, Robert Haas wrote:I think the issues Josh raised are valid concerns for a number of use
> 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....
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
EnterpriseDB Corporation
The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: