| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
| Cc: | Andrew McMillan <andrew(at)catalyst(dot)net(dot)nz>, Sean Chittenden <sean(at)chittenden(dot)org>, Peter Eisentraut <peter_e(at)gmx(dot)net>, PGBugs List <pgsql-bugs(at)postgresql(dot)org> |
| Subject: | Re: ALTER USER SET log_* not allowed... |
| Date: | 2004-11-10 17:55:47 |
| Message-ID: | 14164.1100109347@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2004-11-10 18:17:16 | Re: ALTER USER SET log_* not allowed... |
| Previous Message | Tom Lane | 2004-11-10 17:38:56 | Re: bugreport 7.4.5 |