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: