Re: [HACKERS] Superowners - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: [HACKERS] Superowners
Date
Msg-id 20170130035148.GT9812@tamriel.snowman.net
Whole thread Raw
In response to Re: [HACKERS] Superowners  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
List 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 by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: [HACKERS] Transactions involving multiple postgres foreign servers
Next
From: Nikita Glukhov
Date:
Subject: [HACKERS] [PATCH]: fix bug in SP-GiST box_ops