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...
|
Список | 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 по дате отправления: