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.
> 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.
(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.)
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
