Re: Additional role attributes && superuser review

On Wed, Feb 03, 2016 at 01:44:28PM -0500, Robert Haas wrote:
> On Thu, Jan 28, 2016 at 4:37 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> > pg_monitor
> >
> > Allows roles granted more information from pg_stat_activity. Can't be
> > just a regular non-default-role right as we don't, currently, have a
> > way to say "filter out the values of certain columns on certain rows,
> > but not on others."
> >
> > (There's a question here though- for the privileges which will be
> > directly GRANT'able, should we GRANT those to pg_monitor, or have
> > pg_monitor only provide unfiltered access to pg_stat_activity, or..?
> > Further, if it's only for pg_stat_activity, should we name it
> > something else?)
>
> I endorse this proposed role. I'd have it just grant access to
> pg_stat_activity but keep the name pg_monitor so that it could apply
> to other similar things in the future, but there might be other good
> alternatives too.

-1 for adding any pg_monitor role. That name belongs to a role allowing, from
inception, more than just full pg_stat_activity access. The last, vigorous
effort to define its scope failed; there may not exist one notion of
"monitoring" operations qualified to claim this name. At least, the community
lacks the ability to design it in the foreseeable future.

> > pg_signal_backend
> >
> > Allows roles to signal other backend processes beyond those backends
> > which are owned by a user they are a role member of. Can't be a
> > regular non-default-role right as we don't, currently, have any way to
> > GRANT rights to send signals only to backends you own or are a member
> > of.
>
> I also endorse this.

+1. This role has a clear scope and a name denoting that scope, so it's a
sound way to introduce built-in role infrastructure. I like the concept of
built-in roles. One can inherit them via user-defined roles and use NOINHERIT
to regulate that. One can grant WITH ADMIN OPTION, something role options
like REPLICATION don't offer. It feels more scalable than defining role
options, and it's a technique non-core code can imitate.

I haven't decided whether it's a problem that members of built-in roles can
create objects owned by those roles.