Thread: pgsql: Allow group access on PGDATA
Allow group access on PGDATA Allow the cluster to be optionally init'd with read access for the group. This means a relatively non-privileged user can perform a backup of the cluster without requiring write privileges, which enhances security. The mode of PGDATA is used to determine whether group permissions are enabled for directory and file creates. This method was chosen as it's simple and works well for the various utilities that write into PGDATA. Changing the mode of PGDATA manually will not automatically change the mode of all the files contained therein. If the user would like to enable group access on an existing cluster then changing the mode of all the existing files will be required. Note that pg_upgrade will automatically change the mode of all migrated files if the new cluster is init'd with the -g option. Tests are included for the backend and all the utilities which operate on the PG data directory to ensure that the correct mode is set based on the data directory permissions. Author: David Steele <david@pgmasters.net> Reviewed-By: Michael Paquier, with discussion amongst many others. Discussion: https://postgr.es/m/ad346fe6-b23e-59f1-ecb7-0e08390ad629%40pgmasters.net Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/c37b3d08ca6873f9d4eaf24c72a90a550970cbb8 Modified Files -------------- doc/src/sgml/config.sgml | 17 ++++ doc/src/sgml/ref/initdb.sgml | 19 +++++ doc/src/sgml/ref/pg_basebackup.sgml | 6 ++ doc/src/sgml/ref/pg_receivewal.sgml | 6 ++ doc/src/sgml/ref/pg_recvlogical.sgml | 11 +++ doc/src/sgml/runtime.sgml | 26 +++++- src/backend/bootstrap/bootstrap.c | 12 +-- src/backend/postmaster/postmaster.c | 87 ++++---------------- src/backend/tcop/postgres.c | 3 +- src/backend/utils/init/globals.c | 9 +++ src/backend/utils/init/miscinit.c | 115 ++++++++++++++++++++++++--- src/backend/utils/misc/guc.c | 25 ++++++ src/bin/initdb/initdb.c | 29 ++++++- src/bin/initdb/t/001_initdb.pl | 20 ++++- src/bin/pg_basebackup/pg_basebackup.c | 26 ++++-- src/bin/pg_basebackup/pg_receivewal.c | 11 +++ src/bin/pg_basebackup/pg_recvlogical.c | 11 +++ src/bin/pg_basebackup/streamutil.c | 76 ++++++++++++++++++ src/bin/pg_basebackup/t/010_pg_basebackup.pl | 21 ++++- src/bin/pg_ctl/pg_ctl.c | 12 ++- src/bin/pg_ctl/t/001_start_stop.pl | 25 +++++- src/bin/pg_resetwal/pg_resetwal.c | 10 +++ src/bin/pg_rewind/RewindTest.pm | 9 ++- src/bin/pg_rewind/pg_rewind.c | 11 +++ src/bin/pg_rewind/t/002_databases.pl | 13 ++- src/bin/pg_upgrade/pg_upgrade.c | 12 ++- src/bin/pg_upgrade/test.sh | 16 ++-- src/common/file_perm.c | 72 ++++++++++++++++- src/include/common/file_perm.h | 24 +++++- src/include/miscadmin.h | 2 + src/test/perl/PostgresNode.pm | 27 ++++++- src/test/perl/TestLib.pm | 25 ++++++ 32 files changed, 661 insertions(+), 127 deletions(-)
On Sat, Apr 7, 2018 at 2:46 PM, Stephen Frost <sfrost@snowman.net> wrote:
> Allow group access on PGDATA
>
> Allow the cluster to be optionally init'd with read access for the
> group.
Looks like this broke prion and culicidae. On culicidae, clearly the
problem is here:
"""
Upgrade Complete
----------------
Optimizer statistics are not transferred by pg_upgrade so,
once you start the new server, consider running:
./analyze_new_cluster.sh
Running this script will delete the old cluster's data files:
./delete_old_cluster.sh
+ find /home/andres/build/buildfarm-culicidae/HEAD/pgsql.build/src/bin/pg_upgrade/tmp_check/data
-type f ! -perm 640
+ wc -l
+ [ 1778 -ne 0 ]
+ echo files in PGDATA with permission != 640
files in PGDATA with permission != 640
+ exit 1
+ rm -rf /tmp/pg_upgrade_check-h6epmk
make: *** [Makefile:40: check] Error 1
"""
--
Peter Geoghegan
Peter Geoghegan <pg@bowt.ie> writes:
> On Sat, Apr 7, 2018 at 2:46 PM, Stephen Frost <sfrost@snowman.net> wrote:
>> Allow group access on PGDATA
> Looks like this broke prion and culicidae.
prion's problem seems to be ye same old postgres_fdw plan instability.
(We really need to buckle down and find the cause of that. I have
already spent a lot of cycles trying to reproduce it outside the
buildfarm, with no success.)
regards, tom lane
Peter, * Peter Geoghegan (pg@bowt.ie) wrote: > On Sat, Apr 7, 2018 at 2:46 PM, Stephen Frost <sfrost@snowman.net> wrote: > > Allow group access on PGDATA > > > > Allow the cluster to be optionally init'd with read access for the > > group. > > Looks like this broke prion and culicidae. On culicidae, clearly the > problem is here: The error on prion is pretty clearly unrelated and has to do with postgres_fdw plan instability, as discussed elsewhere recently.. > """ > Upgrade Complete > ---------------- > Optimizer statistics are not transferred by pg_upgrade so, > once you start the new server, consider running: > ./analyze_new_cluster.sh > > Running this script will delete the old cluster's data files: > ./delete_old_cluster.sh > + find /home/andres/build/buildfarm-culicidae/HEAD/pgsql.build/src/bin/pg_upgrade/tmp_check/data > -type f ! -perm 640 > + wc -l > + [ 1778 -ne 0 ] > + echo files in PGDATA with permission != 640 > files in PGDATA with permission != 640 > + exit 1 > + rm -rf /tmp/pg_upgrade_check-h6epmk > make: *** [Makefile:40: check] Error 1 > """ Yes, that's the error, the question is what's different about that member from the others where things are working as expected. I was a bit nervous that the test here might be overly optimistic about what it can expect on buildfarm members. Chatting with David about it currently. Thanks! Stephen