Re: Read access for pg_monitor to pg_replication_origin_status view
От | Martín Marqués |
---|---|
Тема | Re: Read access for pg_monitor to pg_replication_origin_status view |
Дата | |
Msg-id | CAPdiE1ycTSR+2d2xQ5C1LGfooBaAv+ZAW1vGXq7bCB7wFfDzQA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Read access for pg_monitor to pg_replication_origin_status view (Martín Marqués <martin@2ndquadrant.com>) |
Ответы |
Re: Read access for pg_monitor to pg_replication_origin_status view
Re: Read access for pg_monitor to pg_replication_origin_status view |
Список | pgsql-hackers |
Hi, Took me a bit longer than expected, but here is a new version, now with the idea of just removing the superuser() check and REVOKEing execution of the functions from public. At the end I grant permission to functions and the pg_replication_origin_status view. I wonder now if I needed to GRANT execution of the functions. A grant on the view should be enough. I'll think about it. El dom., 31 de may. de 2020 a la(s) 12:13, Martín Marqués (martin@2ndquadrant.com) escribió: > > Hi Michael, > > > Wouldn't it be just better to remove this hardcoded superuser check > > and replace it with equivalent ACLs by default? The trick is to make > > sure that any function calling replorigin_check_prerequisites() has > > its execution correctly revoked from public. See for example > > e79350fe. > > Looking at that, it seems a better solution. Let me wrap up a new > patch, likely later today or early tomorrow as it's Sunday ;-) > > -- > Martín Marqués http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Training & Services -- Martín Marqués http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Вложения
В списке pgsql-hackers по дате отправления: