On 3/6/17 8:17 AM, Robert Haas wrote:
> On Mon, Mar 6, 2017 at 7:38 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Simon Riggs <simon@2ndquadrant.com> writes:
>>> On 1 March 2017 at 01:58, David Steele <david@pgmasters.net> wrote:
>>>> PostgreSQL currently requires the file mode mask (umask) to be 0077.
>>>> However, this precludes the possibility of a user in the postgres group
>>>> performing a backup (or whatever). Now that
>>>> pg_start_backup()/pg_stop_backup() privileges can be delegated to an
>>>> unprivileged user, it makes sense to also allow a (relatively)
>>>> unprivileged user to perform the backup at the file system level as well.
>>
>>> +1
>>
>> I'd ask what is the point, considering that we don't view "cp -a" as a
>> supported backup technique in the first place.
>
> /me is confused.
>
> Surely the idea is that you'd like an unprivileged database user to
> run pg_start_backup(), an operating system user that can read but not
> write the database files to copy them, and then the unprivileged to
> then run pg_stop_backup(). I have no opinion on the patch, but I
> support the goal. As I said on the surprisingly-controversial thread
> about ripping out hard-coded superuser checks, reducing the level of
> privilege which someone must have in order to perform a necessary
> operation leads to better security. An exclusive backup taken via the
> filesystem (probably not via cp, but say via tar or cpio) inevitably
> requires the backup user to be able to read the entire cluster
> directory, but it doesn't inherently require the backup user to be
> able to write the cluster directory.
Limiting privileges also serves to guard against any bugs in tools that
run directly against $PGDATA and do not require write privileges.
--
-David
david@pgmasters.net
