Re: Additional role attributes && superuser review

On Tue, Dec 30, 2014 at 6:52 AM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> > >There is one issue that occurs to me, however. We're talking about
> > >pg_dump, but what about pg_dumpall? In particular, I don't think the
> > >DUMP privilege should provide access to pg_authid, as that would allow
> > >the user to bypass the privilege system in some environments by using
> > >the hash to log in as a superuser. Now, I don't encourage using
> > >password based authentication, especially for superuser accounts, but
> > >lots of people do. The idea with these privileges is to allow certain
> > >operations to be performed by a non-superuser while preventing trivial
> > >access to superuser. Perhaps it's pie-in-the-sky, but my hope is to
> > >achieve that.
> >
> > Ugh, hadn't thought about that. :(
>
> I don't think it kills the whole idea, but we do need to work out how to
> address it.
>

One way to address this might be to allow this only for superusers,
another could be have a separate privilege (DBA) or a role which is
not a superuser, however can be used to perform such tasks.

> > >>* BACKUP - allows role to perform backup operations (as originally
proposed)
> > >>* LOG - allows role to rotate log files - remains broad enough to
consider
> > >>future log related operations
> > >>* DUMP - allows role to perform pg_dump* backups of whole database
> > >>* MONITOR - allows role to view pg_stat_* details (as originally
proposed)
> > >>* PROCSIGNAL - allows role to signal backend processes (as originally
> > >>proposed)well
> >
> > Given the confusion that can exist with the data reading stuff, perhaps
BINARY BACKUP or XLOG would be a better term, especially since this will
probably have some overlap with streaming replication.
>
> I don't really like 'xlog' as a permission. BINARY BACKUP is
> interesting but if we're going to go multi-word, I would think we would
> do PITR BACKUP or something FILESYSTEM BACKUP or similar. I'm not
> really a big fan of the two-word options though.
>

How about PHYSICAL BACKUP (for basebackup) and LOGICAL BACKUP
for pg_dump?

This is normally the terminology I have seen people using for these
backup's.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com