|From:||David Steele <david(at)pgmasters(dot)net>|
|To:||Pg Hackers <pgsql-hackers(at)postgresql(dot)org>|
|Cc:||Adam Brightwell <adam(dot)brightwell(at)crunchydata(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>|
|Subject:||PATCH: Configurable file mode mask|
|Views:||Raw Message | Whole Thread | Download mbox|
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.
This patch introduces a new initdb param, -u/-file-mode-mask, and a new
GUC, file_mode_mask, to allow the default mode of files and directories
in the $PGDATA directory to be modified.
This obviously required mode changes in a number of places, so at the
same time the BasicOpenFile(), OpenTransientFile(), and
PathNameOpenFile() have been split into versions that either use the
default permissions or allow custom permissions. In the end there was
only one call to the custom permission version (be-fsstubs.c:505) for
all three variants.
The following three calls (at the least) need to be reviewed:
And this call needs serious consideration:
Besides that there should be tests to make sure the masks are working as
expected and these could be added to the initdb TAP tests, though no
mask tests exist at this time. Making sure all file operations produce
the correct modes would need to be placed in a new module, perhaps the
new backup tests proposed in .
Adam Brightwell developed the patch based on an initial concept by me
and Stephen Frost. I added the refactoring in fd.c and some additional
This patch applies cleanly on 016c990 but may fare badly over time due
to the number of files modified.
|Next Message||Haribabu Kommi||2017-03-01 01:59:46||Refactor handling of database attributes between pg_dump and pg_dumpall|
|Previous Message||Amit Langote||2017-03-01 01:36:24||Re: Declarative partitioning optimization for large amount of partitions|