Re: Audit of logout
От | Fujii Masao |
---|---|
Тема | Re: Audit of logout |
Дата | |
Msg-id | CAHGQGwE36i3RsmW4_3rGMMTDV_4zED6FzMZtx=A3xVbSgN3p9g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Audit of logout (Magnus Hagander <magnus@hagander.net>) |
Ответы |
Re: Audit of logout
|
Список | pgsql-hackers |
On Tue, Jul 15, 2014 at 10:45 PM, Magnus Hagander <magnus@hagander.net> wrote: > On Wed, Jul 2, 2014 at 10:52 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> I wrote: >>> In short, maybe we ought to invent a new category PGC_SU_BACKEND (not >>> wedded to this spelling), which is to PGC_BACKEND as PGC_SUSET is to >>> PGC_USERSET, ie same when-it-can-be-changed behavior but only superusers >>> are allowed to change it. I don't have any objection to making these two >>> settings only adjustable by superusers --- I just don't want to give up >>> the existing timing restrictions for them. >> >> Another idea would be to get rid of PGC_SUSET as a separate category, and >> instead have a superuser-only bit in the GUC flags, which would apply to >> all categories. This would be a bit more orthogonal, though likely a >> much more invasive change. > > That could become interesting in the futuren ow that we have ALTER > SYSTEM SET. It could allow a non-superuser to make persistent > configuration changes. Now, I'm not sure we actually *want* that > though... But having it as a separate bit would make it possible for > ALTER SYSTEM SET to say that for example regular users would be able > to change work_mem persistently. But if we want to go down that route, > we might need a more fine grained permissions model than just > superuser vs non-superuser... > > I think going with the PGC_SU_BACKEND is the right choice at this > time, until we have an actual usecase for the other :) Yep, the attached patch introduces PGC_SU_BACKEND and changes the contexts of log_connections and log_disconnections to PGC_SU_BACKEND. Review? Regards, -- Fujii Masao
Вложения
В списке pgsql-hackers по дате отправления: