Re: Read access for pg_monitor to pg_replication_origin_status view

Поиск
Список
Период
Сортировка
От Masahiko Sawada
Тема Re: Read access for pg_monitor to pg_replication_origin_status view
Дата
Msg-id CA+fd4k6OuoNteNo3oAK0snobR0i7rr+88S96GkTH0KjVJ0ZYMg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Read access for pg_monitor to pg_replication_origin_status view  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: Read access for pg_monitor to pg_replication_origin_status view  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers
On Tue, 9 Jun 2020 at 16:36, Michael Paquier <michael@paquier.xyz> wrote:
>
> On Tue, Jun 09, 2020 at 03:32:24PM +0900, Masahiko Sawada wrote:
> > One thing I'm concerned with this change is that we will end up
> > needing to grant both execute on pg_show_replication_origin_status()
> > and select on pg_replication_origin_status view when we want a
> > non-super user to access pg_replication_origin_status. It’s unlikely
> > that the user can grant both privileges at once as
> > pg_show_replication_origin_status() is not documented.
>
> Not sure if that's worth worrying.  We have similar cases like that,
> take for example pg_file_settings with pg_show_all_file_settings()
> which requires both a SELECT ACL on pg_file_settings and an EXECUTE
> ACL on pg_show_all_file_settings().  My point is that if you issue a
> GRANT SELECT on the catalog view, the user can immediately see when
> trying to query it that an extra execution is needed.

Oh, I see. There might be room for improvement but it's a separate issue.

I agreed with the change you proposed.

Regards,

--
Masahiko Sawada            http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



В списке pgsql-hackers по дате отправления:

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: Speedup usages of pg_*toa() functions
Следующее
От: Kyotaro Horiguchi
Дата:
Сообщение: Re: Read access for pg_monitor to pg_replication_origin_status view