From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Harold Giménez <harold(at)heroku(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: proposal: hide application_name from other users |
Date: | 2014-01-21 16:38:26 |
Message-ID: | 20140121163826.GQ31026@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* Magnus Hagander (magnus(at)hagander(dot)net) wrote:
> On Tue, Jan 21, 2014 at 5:18 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> > Not unless we change it to allow read-access to all tables to allow for
> > pg_dump to work...
>
> That sounds more like CAP_DUMP than CAP_BACKUP :)
Well, perhaps CAP_READONLY (or READALL?), there are auditor-type roles
which could be reduced to that level instead of superuser. I'm on the
fence about if this needs to be seperate from REPLICATION though- how
many different such options are we going to have and how ugly is it
going to get to litter the code with if(superuser || read-only || ...)?
Perhaps a way to say "this role has X-privilege on all objects of this
type" which could then be used to GRANT SELECT and would be a single
point where we need to add those checks (in the ACL code for each
object type)? One of the key points would be that the privilege apply
to newly created objects as well..
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2014-01-21 16:41:13 | Re: Closing commitfest 2013-11 |
Previous Message | Robert Haas | 2014-01-21 16:37:35 | Re: dynamic shared memory and locks |