On Mon, Jan 26, 2015 at 1:59 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> On 2015-01-26 13:47:02 -0500, Stephen Frost wrote:
>> * Robert Haas (robertmhaas@gmail.com) wrote:
>> > On Wed, Jan 21, 2015 at 11:27 AM, Adam Brightwell
>> > <adam.brightwell@crunchydatasolutions.com> wrote:
>> > > After re-reading through this thread is seems like EXCLUSIVEBACKUP (proposed
>> > > by Magnus) seemed to be a potentially acceptable alternative.
>> >
>> > So this would let you do pg_start_backup() and pg_stop_backup(), but
>> > it wouldn't let you run pg_basebackup against the server?
>>
>> Right. We already have a role attribute which allows pg_basebackup
>> (replication). Also, with pg_basebackup / rolreplication, your role
>> is able to read the entire data directory from the server, that's not
>> the case with only rights to run pg_start/stop_backup.
>>
>> In conjunction with enterprise backup solutions and SANs, which offer
>> similar controls where a generally unprivileged user can have a snapshot
>> of the system taken through the SAN interface, you can give users the
>> ability to run ad-hoc backups of the cluster without giving them
>> superuser-level access or replication-level access.
>
> I'm sorry if this has already been discussed, but the thread is awfully
> long already. But what's actually the point of having a separate
> EXCLUSIVEBACKUP permission? Using it still requires full file system
> access to the data directory, so the additional permissions granted by
> replication aren't really relevant.
That's not necessarily true. You could be able to run a command like
"san_snapshot $PGDATA" without necessarily having the permissions to
inspect the contents of the resulting snapshot. Of course somebody
should be doing that, but in accord with the principle of least
privilege, there's no reason that the account running the unattended
backup needs to have those rights.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
