On Sun, Jan 17, 2016 at 09:10:23PM -0500, Stephen Frost wrote:
> > While the group owner of the directory is a distributions question, the
> > permissions are usually a backup-method-specific requirement. I can see
> > us creating an SQL function that opens up group permissions on the data
> > directory for specific backup tools that need it, then granting
> > permissions on that function to the backup role. This is another
> > example where different backup tools need different permissions.
>
> I don't believe we can really consider group ownership and group
> permissions independently. They really go hand-in-hand. On
> RedHat-based system, where the group is set as 'staff', you probably
> don't want group permissions to be allowed. On Debian-based systems,
> where there is a dedicated 'postgres' group, group permissions are fine
> to allow.
Yes, I can see that as problematic. Seems it would have to be something
done by the administrator from the command-line.
> Group ownership and permissions aren't a backup-method-specific
> requirement either, in my view. I'm happy to chat with Marco (who has
> said he would be weighing in on this thread when he is able to)
> regarding barman, and whomever would be appropriate for BART (perhaps
> you could let me know..?), but if it's possible to do a backup without
> being a superuser and with only read access to the data directory, I
> would expect every backup soltuion to view that as a feature which they
> want to support, as there are environments which will find it desirable,
> at a minimum, and even some which will require it.
pg_dump doesn't need to read the PGDATA directory, and I thought this
permission was to be used by pg_dump users as well.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Roman grave inscription +
