Re: proposal: hide application_name from other users

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

In response to

Browse pgsql-hackers by date

  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