Re: Additional role attributes && superuser review

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Noah Misch <noah(at)leadboat(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Robert Haas <robertmhaas(at)gmail(dot)com>, David Steele <david(at)pgmasters(dot)net>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Adam Brightwell <adam(dot)brightwell(at)crunchydatasolutions(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Petr Jelinek <petr(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Additional role attributes && superuser review
Date: 2016-01-18 02:23:14
Message-ID: 20160118022314.GK3685@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* Bruce Momjian (bruce(at)momjian(dot)us) wrote:
> 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.

initdb on both RedHat and Debian-based systems is run, generally
speaking, from the packaging scripts. They would be able to pass the
correct options to initdb (or PG itself, if we decide that's
necessary..).

> > 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.

No. That has been a source of confusion, though I'm not quite sure how
or why, beyond the general assumption that anything 'backup' must
include 'pg_dump' (I don't generally consider that to be the case,
myself, but it seems others do...).

This is only for file-based backups.

Thanks!

Stephen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2016-01-18 02:26:30 Re: Combining Aggregates
Previous Message Bruce Momjian 2016-01-18 02:20:44 Re: Additional role attributes && superuser review