Re: ALTER USER SET log_* not allowed...

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: ALTER USER SET log_* not allowed...
Дата
Msg-id 200411101817.iAAIHGX13988@candle.pha.pa.us
обсуждение исходный текст
Ответ на Re: ALTER USER SET log_* not allowed...  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: ALTER USER SET log_* not allowed...  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-bugs
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Tom Lane wrote:
> >> Sure.  There is a workaround for that though, which is to provide a
> >> SECURITY DEFINER function for the app to call that will adjust the
> >> logging level for it, rather than trying to do the SET directly in
> >> unprivileged code.
>
> > But if they go that way can it done securely, turned on and off?
>
> Why not?  You can put whatever restrictions you like in such a function.
>
> It'd certainly be more "secure" than the existing USERLIMIT behavior,
> because the DBA can decide exactly what policy he wants and code it
> into the function he gives his users (maybe even multiple functions for
> different users).  USERLIMIT effectively dictates to the DBA what will
> be allowed.

But right now the userlimit codes allows a non-super user to turn
logging on only if it was off, and he can then turn it off again.

I assume to do this in a function you would have to create a temp table
to store the original setting?  Doesn't sound trivial, nor does it sound
like something someone is going to write just for a single debug session.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: ALTER USER SET log_* not allowed...
Следующее
От: Tom Lane
Дата:
Сообщение: Re: ALTER USER SET log_* not allowed...