Re: should we allow users with a predefined role to access pg_backend_memory_contexts view and pg_log_backend_memory_contexts function?
От | Robert Haas |
---|---|
Тема | Re: should we allow users with a predefined role to access pg_backend_memory_contexts view and pg_log_backend_memory_contexts function? |
Дата | |
Msg-id | CA+TgmobQoWZn62qWRX+OOFjBPhdubxYTBeO-GSNPcLvBHh4ZvA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: should we allow users with a predefined role to access pg_backend_memory_contexts view and pg_log_backend_memory_contexts function? (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: should we allow users with a predefined role to access pg_backend_memory_contexts view and pg_log_backend_memory_contexts function?
|
Список | pgsql-hackers |
On Tue, Oct 12, 2021 at 8:33 PM Stephen Frost <sfrost@snowman.net> wrote: > Or not. I can see the argument that, because it just goes into the log, that it doesn’t make sense to grant to a predefinedrole, since that role wouldn’t be able to see the results even if it had access. Yeah. I think we should really only use predefined roles where it's not practical to have people use GRANT/REVOKE. For instance, it makes sense to have pg_execute_server_program because there's no particular function (or other object) to which you could grant permissions at the SQL level to achieve the same results. And pg_read_all_stats doesn't just allow you to run more functions: it changes which fields those functions populate in the returned data, and which they mask out for security reasons. So, GRANT/REVOKE wouldn't do it in that case. But if there's one particular function that someone may or may not want a non-superuser to be able to execute, let's just let them do that. It doesn't need to be tied to a predefined role, and in fact it's more flexible if it isn't. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: