Re: [HACKERS] Superowners

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: [HACKERS] Superowners
Дата
Msg-id 20170130035148.GT9812@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: [HACKERS] Superowners  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Список pgsql-hackers
Jim,

* Jim Nasby (Jim.Nasby@BlueTreble.com) wrote:
> On 1/29/17 4:44 PM, Stephen Frost wrote:
> >* Peter Eisentraut (peter.eisentraut@2ndquadrant.com) wrote:
> >>On 1/26/17 1:25 PM, Simon Riggs wrote:
> >>>That should include the ability to dump all objects, yet without any
> >>>security details. And it should allow someone to setup logical
> >>>replication easily, including both trigger based and new logical
> >>>replication. And GRANT ON ALL should work.
> >>This basically sounds like a GRANT $privilege ON ALL $objecttype TO
> >>$user.  So you could have a user that can read everything, for example.
> >>
> >>This kind of thing has been asked for many times, but that quieted down
> >>when the default privileges feature appeared.  I think it would still be
> >>useful.
> >Agreed.  I would think we'd either do this with a default role or a role
> >attribute.
>
> Someone was asking for that on Slack the other day, because their
> customer wanted it. Default privs would not fit the bill: they
> wanted to grant specific roles the ability to read everything in the
> database (or maybe cluster; I don't think the conversation got into
> that level of detail).

... eh?  If we create a default role called "pg_read_only" which admins
can grant to whomever they wish, how does that not "fit the bill"?

For my 2c, at least, evaluating the various requests and coming up with
some set of default roles and then implementing them would be a good
GSoC project..

Thanks!

Stephen

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

Предыдущее
От: Ashutosh Bapat
Дата:
Сообщение: Re: [HACKERS] Transactions involving multiple postgres foreign servers
Следующее
От: Nikita Glukhov
Дата:
Сообщение: [HACKERS] [PATCH]: fix bug in SP-GiST box_ops