Re: Additional role attributes && superuser review

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Petr Jelinek <petr(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Additional role attributes && superuser review
Date: 2014-10-16 15:47:51
Message-ID: 20141016154751.GE28859@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro,

* Alvaro Herrera (alvherre(at)2ndquadrant(dot)com) wrote:
> Stephen Frost wrote:
> > * Petr Jelinek (petr(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2014-10-16 16:01:28 Re: Directory/File Access Permissions for COPY and Generic File Access Functions
Previous Message Ryan Johnson 2014-10-16 15:33:03 Re: WIP: dynahash replacement for buffer table