Alvaro,
* Alvaro Herrera (alvherre@2ndquadrant.com) wrote:
> Stephen Frost wrote:
> > * Petr Jelinek (petr@2ndquadrant.com) wrote:
> > > On 15/10/14 07:22, Stephen Frost wrote:
> > > > First though, the new privileges, about which the bikeshedding can
> > > > begin, short-and-sweet format:
> > > >
> > > > BACKUP:
> > > > pg_start_backup()
> > > > pg_stop_backup()
> > > > pg_switch_xlog()
> > > > pg_create_restore_point()
> > >
> > > As others have commented, I too think this should support pg_dump.
> >
> > I'm uttly mystified as to what that *means*. Everyone asking for it is
> > great but until someone can define what "support pg_dump" means, there's
> > not much progress I can make towards it..
>
> To me, what this repeated discussion on this particular BACKUP point
> says, is that the ability to run pg_start/stop_backend and the xlog
> related functions should be a different privilege, i.e. something other
> than BACKUP; because later we will want the ability to grant someone the
> ability to run pg_dump on the whole database without being superuser,
> and we will want to use the name BACKUP for that. So I'm inclined to
> propose something more specific for this like WAL_CONTROL or
> XLOG_OPERATOR, say.
Ok. Not sure that I see 'XLOG_OPERATOR' as making sense for
'pg_start_backup' though, and I see the need to support pg_dump'ing the
whole database as a non-superuser being more like a 'READONLY' kind of
role.
We've actually already looked at the notion of a 'READONLY' or 'READALL'
role attribute and, well, it's quite simple to implement.. We're
talking about a few lines of code to implicitly allow 'USAGE' on all
schemas, plus a minor change in ExecCheckRTEPerms to always (or perhaps
*only*) include SELECT rights. As there's so much interest in that
capability, perhaps we should add it..
One of the big question is- do we take steps to try and prevent a role
with this attribute from being able to modify the database in any way?
Or would this role attribute only ever increase your rights?
> > pg_dump doesn't require superuser rights today. If you're looking for a
> > role which allows a user to arbitrairly read all data, fine, but that's
> > a different consideration and would be a different role attribute, imv.
> > If you'd like the role attribute renamed to avoid confusion, I'm all for
> > that, just suggest something.
>
> There.
Fair enough, just don't like the specific suggestions. :) In the docs,
we talk about pg_start_backup being for 'on-line' backups, perhaps we
use ONLINE_BACKUP ? Or PITR_BACKUP ?
> (Along the same lines, perhaps the log rotate thingy that's being
> mentioned elsewhere could be LOG_OPERATOR instead of just OPERATOR, to
> avoid privilege "upgrades" as later releases include more capabilities
> to the hypothetical OPERATOR capability.)
I'd be fine calling it LOG_OPERATOR instead, sure.
Thanks!
Stephen
