Re: Additional role attributes && superuser review - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Additional role attributes && superuser review
Date
Msg-id CA+TgmoZQXD0tQtvoFq03ui1_dhpdmpk_fNGC3YUtutN9iHc=Bg@mail.gmail.com
Whole thread Raw
In response to Re: Additional role attributes && superuser review  (Stephen Frost <sfrost@snowman.net>)
Responses Re: Additional role attributes && superuser review
List pgsql-hackers
On Thu, Jan 28, 2016 at 4:37 PM, Stephen Frost <sfrost@snowman.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.

> 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.

> pg_replication
>
>   Allows roles to use the various replication functions.  Can't be a
>   regular non-default-role right as the REPLICATION role attribute
>   allows access to those functions and the GRANT system has no way of
>   saying "allow access to these functions if they have role attribute
>   X."
>
> Make sense, as these are cases where we can't simply write GRANT
> statements and get the same result, but we don't need (or at least,
> shouldn't have without supporting GRANT on catalog objects and agreement
> on what they're intended for):

This seems like it could be reshuffled so that it can be done with
GRANT.  Therefore, I don't endorse this.

> pg_backup
>
>   pg_start_backup(), pg_stop_backup(), pg_switch_xlog(), and
>   pg_create_restore_point() will all be managed by the normal GRANT
>   system and therefore we don't need a default role for those use-cases.

Agreed.

> pg_file_settings
>
>   pg_file_settings() function and pg_file_settings view will be managed
>   by the normal GRANT system and therefore we don't need a default role
>   for those use-cases.

Agreed.

> pg_replay
>
>   pg_xlog_replay_pause(), and pg_xlog_replay_resume() will be managed
>   by the normal GRANT system and therefore we don't need a default role
>   for those use-cases.

Agreed.

> pg_rotate_logfile
>
>   pg_rotate_logfile() will be managed by the normal GRANT system and
>   therefore we don't need a default role for that use-cases.

Agreed.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: PostgreSQL Audit Extension
Next
From: Robert Haas
Date:
Subject: Re: WIP: Detecting SSI conflicts before reporting constraint violations