Re: PATCH: Configurable file mode mask - Mailing list pgsql-hackers

David,

* David Steele (david@pgmasters.net) wrote:
> On 3/16/18 11:12 AM, Stephen Frost wrote:
> >
> >>> Visibly there would be no need for a -g switch in
> >>> pg_basebackup as it is possible to guess from the received untar'ed
> >>> files what should be the permissions of the data based on what is
> >>> received in pg_basebackup.c.  It would also be necessary to change the
> >>> permissions of pg_wal as this is created before receiving any files.
> >>
> >> This part might be trickier.
> >
> > This seems like another case where what we should be doing, and what
> > people will be expecting, I'd think, is just what they're used to tar
> > doing in these cases- which would be setting the dir/file mode for each
> > file based on what's in the tarball.  Again, the files which are in the
> > data dir are, sadly, not always just those that PG is familiar with.
>
> I've been working on this and have become convinced that adding group
> permissions to files that pg_basebackup writes to disk based on whether
> group permissions are enabled in PGDATA isn't the right way to go.
>
> To be clear, I'm not taking about the permissions set within the tar
> file - I think it makes sense to use the actual PGDATA permissions in
> that case.

What that implies then, if I'm following, is that the results of a
pg_basebackup -Ft && tar -xvf ; would be different from the results of a
pg_basebackup -Fp ; .

That seems like it would be rather odd and confusing to users and so I
have a hard time agreeing that such an inconsistency makes sense.

> pg_basebackup may not be running as postgres, and even if it is I don't
> think we can assume that group access is appropriate for the files that
> it writes.  It's a different environment and different security rules
> may apply.

Sure, and the same security rules may also apply.  Consider an
environment which is managed through a change management system (as many
are these days...) where the pg_basebackup is being run specifically to
set up a replica (which is quite commonly done..) and then allow a tool
like pgbackrest to use both the primary and the replica for backups,
where pgbackrest is run as an independent user which shares the same
group as the PG user and needs group-read access on the replica.  After
building such a replica, the user would have to do a chmod across the
entire data directory, even though the primary was initialized with
group-read access, or, oddly, perform the pg_basebackup to tar files and
then extract those tar files instead of using the plain format.

The general pg_basebackup->replica process works great today and the
primary and the replica more-or-less match as if they were both initdb'd
the same way, or a backup/restore was done, and not preserving the
privileges as they exist would end up diverging from that.

In these cases we're really talking about the defaults here; as I
mention below, I agree that having the ability to control what ends up
happening definitely makes sense (as tar does...).

> It seems to me that pg_basebackup and pg_receivexlog should have a -g
> option to control the mode of the files that they write to disk (not
> including the modes stored in the tar files).
>
> Or perhaps we should just update the perms in the tar files for now and
> leave the rest alone.

Having options to pg_basebackup to control what's done makes sense to
me- but whatever those options do, I'd expect them to apply equally to
the tar files and to the files extracted with plain mode.  Having those
be different really strikes me as very odd.

Thanks!

Stephen