Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)
В списке pgsql-hackers по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers) |
| Дата | |
| Msg-id | 216264.1627333316@sss.pgh.pa.us обсуждение |
| Ответ на | Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers) (Stephen Frost <sfrost@snowman.net>) |
| Ответы |
Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)
|
| Список | pgsql-hackers |
Stephen Frost <sfrost@snowman.net> writes:
> ... Tom's suggestion
> would work, of course, but it would mean having to create event triggers
> for all the roles in the system, and would those roles who own those
> event triggers be able to disable them..?
Uh, why not? If you own the trigger, you can drop it, so why shouldn't
you be able to temporarily disable it?
> If so, it would almost
> certainly be against the point of an auditing event trigger..
If you want auditing capability, you make an auditor role that is
a member of every other role, and then it owns the trigger. (If
you need to audit superuser actions too, then the auditor has to
be a superuser itself, but that's no worse than before; and I'd
argue that non-superusers shouldn't be able to audit superusers
anyway.)
regards, tom lane
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера