On 3/6/17 8:17 AM, Robert Haas wrote: > On Mon, Mar 6, 2017 at 7:38 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Simon Riggs <si...@2ndquadrant.com> writes: >>> On 1 March 2017 at 01:58, David Steele <da...@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 da...@pgmasters.net -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
