Re: Cross-backend signals and administration (Was: Re: pg_terminate_backend for same-role)
В списке pgsql-hackers по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: Cross-backend signals and administration (Was: Re: pg_terminate_backend for same-role) |
| Дата | |
| Msg-id | 29067.1332856165@sss.pgh.pa.us обсуждение |
| Ответ на | Re: Cross-backend signals and administration (Was: Re: pg_terminate_backend for same-role) (Noah Misch <noah@leadboat.com>) |
| Список | pgsql-hackers |
Noah Misch <noah@leadboat.com> writes:
> On Mon, Mar 26, 2012 at 07:53:25PM -0400, Robert Haas wrote:
>> I think the more important question is a policy question: do we want
>> it to work like this?
> The DBA can customize policy by revoking public execute permissions on
> pg_catalog.pg_terminate_backend and interposing a security definer function
> implementing his checks. For the population who will want something different
> here, that's adequate.
I don't particularly trust solutions that involve modifying
system-defined objects. In this case, a dump and reload would be
sufficient to create a security hole, because the REVOKE would go away.
(Now, I'm not particularly concerned about the issue in the first place.
Just pointing out that for someone who is, the above isn't a great
solution.)
regards, tom lane
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера