pg_basebackup ignores the existing data directory permissions

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
49 messages Options
123
Reply | Threaded
Open this post in threaded view
|

pg_basebackup ignores the existing data directory permissions

Haribabu Kommi-2
Hi Hackers,

During the testing allow group access permissions on the standby database directory,
one of my colleague found the issue, that pg_basebackup doesn't verify whether the existing data directory has the required permissions or not? This issue is not related allow group access permissions. This problem was present for a long time, (I think from the time the pg_basebackup was introduced).

Attached patch fixes the problem similar like initdb by changing the permissions of the data
directory to the required permissions.

Regards,
Haribabu Kommi
Fujitsu Australia

0001-pg_basebackup-Correct-the-existing-directory-permiss.patch (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: pg_basebackup ignores the existing data directory permissions

Michael Paquier-2
On Tue, Feb 12, 2019 at 06:03:37PM +1100, Haribabu Kommi wrote:
> During the testing allow group access permissions on the standby database
> directory, one of my colleague found the issue, that pg_basebackup
> doesn't verify whether the existing data directory has the required
> permissions or not?  This issue is not related allow group access
> permissions. This problem was present for a long time, (I think from
> the time the pg_basebackup was introduced).

In which case this would cause the postmaster to fail to start.

> Attached patch fixes the problem similar like initdb by changing the
> permissions of the data
> directory to the required permissions.

It looks right to me and takes care of the case where group access is
allowed.  Still, we have not seen any complains about the current
behavior either and pg_basebackup is around for some time already, so
I would tend to not back-patch that.  Any thoughts from others?
--
Michael

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: pg_basebackup ignores the existing data directory permissions

Haribabu Kommi-2

On Wed, Feb 13, 2019 at 12:42 PM Michael Paquier <[hidden email]> wrote:
On Tue, Feb 12, 2019 at 06:03:37PM +1100, Haribabu Kommi wrote:
> During the testing allow group access permissions on the standby database
> directory, one of my colleague found the issue, that pg_basebackup
> doesn't verify whether the existing data directory has the required
> permissions or not?  This issue is not related allow group access
> permissions. This problem was present for a long time, (I think from
> the time the pg_basebackup was introduced).

In which case this would cause the postmaster to fail to start.

Yes, the postmaster fails to start, but I feel if pg_basebackup takes care
of correcting the file permissions automatically like initdb, that will be good.
 
> Attached patch fixes the problem similar like initdb by changing the
> permissions of the data
> directory to the required permissions.

It looks right to me and takes care of the case where group access is
allowed.  Still, we have not seen any complains about the current
behavior either and pg_basebackup is around for some time already, so
I would tend to not back-patch that.  Any thoughts from others?

This should back-patch till 11 where the group access is introduced.
Because of lack of complaints, I agree with you that there is no need of
further back-patch.
 
Regards,
Haribabu Kommi
Fujitsu Australia
Reply | Threaded
Open this post in threaded view
|

Re: pg_basebackup ignores the existing data directory permissions

Michael Paquier-2
On Wed, Feb 13, 2019 at 06:42:36PM +1100, Haribabu Kommi wrote:
> This should back-patch till 11 where the group access is introduced.
> Because of lack of complaints, I agree with you that there is no need of
> further back-patch.

I am confused by the link with group access.  The patch you are
sending is compatible down to v11, but we could also do it further
down by just using chmod with S_IRWXU on the target folder if it
exists and is empty.
--
Michael

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: pg_basebackup ignores the existing data directory permissions

Haribabu Kommi-2

On Thu, Feb 14, 2019 at 3:04 PM Michael Paquier <[hidden email]> wrote:
On Wed, Feb 13, 2019 at 06:42:36PM +1100, Haribabu Kommi wrote:
> This should back-patch till 11 where the group access is introduced.
> Because of lack of complaints, I agree with you that there is no need of
> further back-patch.

I am confused by the link with group access.

Apologies to confuse you by linking it with group access. This patch doesn't
have an interaction with group access. From v11 onwards, PostgreSQL server
accepts two set of permissions for the data directory because of group access. 

we have an application that is used to create the data directory with
owner access (0700), but with initdb group permissions option, it automatically
converts to (0750) by the initdb. But pg_basebackup doesn't change it when
it tries to do a backup from a group access server.
 
The patch you are
sending is compatible down to v11, but we could also do it further
down by just using chmod with S_IRWXU on the target folder if it
exists and is empty.

Yes, I agree with you that by changing chmod as you said fixes it in the
back-branches. 

Regards,
Haribabu Kommi
Fujitsu Australia
Reply | Threaded
Open this post in threaded view
|

Re: pg_basebackup ignores the existing data directory permissions

Michael Paquier-2
On Thu, Feb 14, 2019 at 06:34:07PM +1100, Haribabu Kommi wrote:
> we have an application that is used to create the data directory with

Well, initdb would do that happily, so there is no actual any need to
do that to begin with.  Anyway..

> owner access (0700), but with initdb group permissions option, it
> automatically
> converts to (0750) by the initdb. But pg_basebackup doesn't change it when
> it tries to do a backup from a group access server.

So that's basically the opposite of the case I was thinking about,
where you create a path for a base backup with permissions strictly
higher than 700, say 755, and the base backup path does not have
enough restrictions.  And in your case the permissions are too
restrictive because of the application creating the folder itself but
they should be relaxed if group access is enabled.  Actually, that's
something that we may want to do consistently across all branches.  If
an application calls pg_basebackup after creating a path, they most
likely change the permissions anyway to allow the postmaster to
start.
--
Michael

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: pg_basebackup ignores the existing data directory permissions

Magnus Hagander-2
On Thu, Feb 14, 2019 at 9:10 AM Michael Paquier <[hidden email]> wrote:
On Thu, Feb 14, 2019 at 06:34:07PM +1100, Haribabu Kommi wrote:
> we have an application that is used to create the data directory with

Well, initdb would do that happily, so there is no actual any need to
do that to begin with.  Anyway..

> owner access (0700), but with initdb group permissions option, it
> automatically
> converts to (0750) by the initdb. But pg_basebackup doesn't change it when
> it tries to do a backup from a group access server.

So that's basically the opposite of the case I was thinking about,
where you create a path for a base backup with permissions strictly
higher than 700, say 755, and the base backup path does not have
enough restrictions.  And in your case the permissions are too
restrictive because of the application creating the folder itself but
they should be relaxed if group access is enabled.  Actually, that's
something that we may want to do consistently across all branches.  If
an application calls pg_basebackup after creating a path, they most
likely change the permissions anyway to allow the postmaster to
start.

I think it could be argued that neither initdb *or* pg_basebackup should change the permissions on an existing directory, because the admin may have done that intentionally. But when they do create the directory, they should follow the same patterns.
 
--
Reply | Threaded
Open this post in threaded view
|

Re: pg_basebackup ignores the existing data directory permissions

Haribabu Kommi-2

On Thu, Feb 14, 2019 at 8:57 PM Magnus Hagander <[hidden email]> wrote:
On Thu, Feb 14, 2019 at 9:10 AM Michael Paquier <[hidden email]> wrote:
On Thu, Feb 14, 2019 at 06:34:07PM +1100, Haribabu Kommi wrote:
> we have an application that is used to create the data directory with

Well, initdb would do that happily, so there is no actual any need to
do that to begin with.  Anyway..

> owner access (0700), but with initdb group permissions option, it
> automatically
> converts to (0750) by the initdb. But pg_basebackup doesn't change it when
> it tries to do a backup from a group access server.

So that's basically the opposite of the case I was thinking about,
where you create a path for a base backup with permissions strictly
higher than 700, say 755, and the base backup path does not have
enough restrictions.  And in your case the permissions are too
restrictive because of the application creating the folder itself but
they should be relaxed if group access is enabled.  Actually, that's
something that we may want to do consistently across all branches.  If
an application calls pg_basebackup after creating a path, they most
likely change the permissions anyway to allow the postmaster to
start.

I think it could be argued that neither initdb *or* pg_basebackup should change the permissions on an existing directory, because the admin may have done that intentionally. But when they do create the directory, they should follow the same patterns.

Hmm, even if the administrator set some specific permissions to the data directory,
PostgreSQL server doesn't allow server to start if the permissions are not (0700)
for versions less than 11 and (0700 or 0750) for version 11 or later.

To let the user to use the PostgreSQL server, user must change the permissions
of the data directory. So, I don't see a problem in changing the permissions by these
tools.

Regards,
Haribabu Kommi
Fujitsu Australia
Reply | Threaded
Open this post in threaded view
|

Re: pg_basebackup ignores the existing data directory permissions

Michael Paquier-2
On Thu, Feb 14, 2019 at 11:21:19PM +1100, Haribabu Kommi wrote:

> On Thu, Feb 14, 2019 at 8:57 PM Magnus Hagander <[hidden email]> wrote:
>> I think it could be argued that neither initdb *or* pg_basebackup should
>> change the permissions on an existing directory, because the admin may have
>> done that intentionally. But when they do create the directory, they should
>> follow the same patterns.
>
> Hmm, even if the administrator set some specific permissions to the data
> directory, PostgreSQL server doesn't allow server to start if the
> permissions are not (0700) for versions less than 11 and (0700 or
> 0750) for version 11 or later.
Yes, particularly with pg_basebackup -R this adds an extra step in the
user flow.

> To let the user to use the PostgreSQL server, user must change the
> permissions of the data directory. So, I don't see a problem in
> changing the permissions by these tools.

I certainly agree with the point of Magnus that both tools should
behave consistently, and I cannot actually imagine why it would be
useful for an admin to keep a more permissive data folder while all
the contents already have umasks set at the same level as the primary
(or what initdb has been told to use), but perhaps I lack imagination.
If we doubt about potential user impact, the usual, best, answer is to
let back-branches behave the way they do now, and only do something on
HEAD.
--
Michael

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: pg_basebackup ignores the existing data directory permissions

Kyotaro HORIGUCHI-2
At Fri, 15 Feb 2019 08:15:24 +0900, Michael Paquier <[hidden email]> wrote in <[hidden email]>

> On Thu, Feb 14, 2019 at 11:21:19PM +1100, Haribabu Kommi wrote:
> > On Thu, Feb 14, 2019 at 8:57 PM Magnus Hagander <[hidden email]> wrote:
> >> I think it could be argued that neither initdb *or* pg_basebackup should
> >> change the permissions on an existing directory, because the admin may have
> >> done that intentionally. But when they do create the directory, they should
> >> follow the same patterns.
> >
> > Hmm, even if the administrator set some specific permissions to the data
> > directory, PostgreSQL server doesn't allow server to start if the
> > permissions are not (0700) for versions less than 11 and (0700 or
> > 0750) for version 11 or later.
>
> Yes, particularly with pg_basebackup -R this adds an extra step in the
> user flow.

I disagree that pg_basebackup rejects directories other than
specific permissions, since it is just a binary backup tool,
which is not exclusive to making replication-standby. It ought to
be runnable and actually runnable by any OS users even by root,
for who postgres rejects to start. As mentioned upthread, it is
safe-side failure that server rejects to run on it.

> > To let the user to use the PostgreSQL server, user must change the
> > permissions of the data directory. So, I don't see a problem in
> > changing the permissions by these tools.
>
> I certainly agree with the point of Magnus that both tools should
> behave consistently, and I cannot actually imagine why it would be
> useful for an admin to keep a more permissive data folder while all
> the contents already have umasks set at the same level as the primary
> (or what initdb has been told to use), but perhaps I lack imagination.
> If we doubt about potential user impact, the usual, best, answer is to
> let back-branches behave the way they do now, and only do something on
> HEAD.

initdb is to create a directory on which server works and rather
rejects existing directory, so I think the "incosistency" seems
fine.

I can live with some new options, say --create-New-directory or
--check-directory-Permission.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center


Reply | Threaded
Open this post in threaded view
|

Re: pg_basebackup ignores the existing data directory permissions

Michael Paquier-2
On Fri, Feb 15, 2019 at 09:24:15AM +0900, Kyotaro HORIGUCHI wrote:
> I disagree that pg_basebackup rejects directories other than
> specific permissions, since it is just a binary backup tool,
> which is not exclusive to making replication-standby. It ought to
> be runnable and actually runnable by any OS users even by root,
> for who postgres rejects to start. As mentioned upthread, it is
> safe-side failure that server rejects to run on it.

Perhaps I do not fully understand your argument here.  We do not
discuss about making pg_basebackup fail in any way, just of having it
adjust the umask of the target path so as users can simplify startups
using the generated base backup.
--
Michael

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: pg_basebackup ignores the existing data directory permissions

Haribabu Kommi-2
In reply to this post by Michael Paquier-2

On Fri, Feb 15, 2019 at 10:15 AM Michael Paquier <[hidden email]> wrote:
On Thu, Feb 14, 2019 at 11:21:19PM +1100, Haribabu Kommi wrote:
> On Thu, Feb 14, 2019 at 8:57 PM Magnus Hagander <[hidden email]> wrote:
>> I think it could be argued that neither initdb *or* pg_basebackup should
>> change the permissions on an existing directory, because the admin may have
>> done that intentionally. But when they do create the directory, they should
>> follow the same patterns.
>
> Hmm, even if the administrator set some specific permissions to the data
> directory, PostgreSQL server doesn't allow server to start if the
> permissions are not (0700) for versions less than 11 and (0700 or
> 0750) for version 11 or later.

Yes, particularly with pg_basebackup -R this adds an extra step in the
user flow.

> To let the user to use the PostgreSQL server, user must change the
> permissions of the data directory. So, I don't see a problem in
> changing the permissions by these tools.

I certainly agree with the point of Magnus that both tools should
behave consistently, and I cannot actually imagine why it would be
useful for an admin to keep a more permissive data folder while all
the contents already have umasks set at the same level as the primary
(or what initdb has been told to use), but perhaps I lack imagination.
If we doubt about potential user impact, the usual, best, answer is to
let back-branches behave the way they do now, and only do something on
HEAD.

I also agree that both inidb and pg_basebackup should behave same.
Our main concern is that standby data directory that doesn't follow
the primary data directory permissions can lead failures when the standby
gets promoted.

Lack of complaints from the users, how about making this change in the HEAD?

Regards,
Haribabu Kommi
Fujitsu Australia
Reply | Threaded
Open this post in threaded view
|

Re: pg_basebackup ignores the existing data directory permissions

Michael Paquier-2
On Wed, Feb 20, 2019 at 03:16:48PM +1100, Haribabu Kommi wrote:
> Lack of complaints from the users, how about making this change in the HEAD?

Fine by me.  I would tend to patch pg_basebackup so as the target
folder gets the correct umask instead of nuking the chmod call in
initdb so I think that we are on the same page.  Let's see what the
others think.
--
Michael

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: pg_basebackup ignores the existing data directory permissions

Magnus Hagander-2
In reply to this post by Haribabu Kommi-2

On Wed, Feb 20, 2019 at 5:17 AM Haribabu Kommi <[hidden email]> wrote:

On Fri, Feb 15, 2019 at 10:15 AM Michael Paquier <[hidden email]> wrote:
On Thu, Feb 14, 2019 at 11:21:19PM +1100, Haribabu Kommi wrote:
> On Thu, Feb 14, 2019 at 8:57 PM Magnus Hagander <[hidden email]> wrote:
>> I think it could be argued that neither initdb *or* pg_basebackup should
>> change the permissions on an existing directory, because the admin may have
>> done that intentionally. But when they do create the directory, they should
>> follow the same patterns.
>
> Hmm, even if the administrator set some specific permissions to the data
> directory, PostgreSQL server doesn't allow server to start if the
> permissions are not (0700) for versions less than 11 and (0700 or
> 0750) for version 11 or later.

Yes, particularly with pg_basebackup -R this adds an extra step in the
user flow.

Perhaps we should make the enforcement of permissions conditional on -R? OTOH that's documented as "write recovery.conf", but we could change that to be "prepare for replication" or something?


> To let the user to use the PostgreSQL server, user must change the
> permissions of the data directory. So, I don't see a problem in
> changing the permissions by these tools.

I certainly agree with the point of Magnus that both tools should
behave consistently, and I cannot actually imagine why it would be
useful for an admin to keep a more permissive data folder while all
the contents already have umasks set at the same level as the primary
(or what initdb has been told to use), but perhaps I lack imagination.
If we doubt about potential user impact, the usual, best, answer is to
let back-branches behave the way they do now, and only do something on
HEAD.

I also agree that both inidb and pg_basebackup should behave same.
Our main concern is that standby data directory that doesn't follow
the primary data directory permissions can lead failures when the standby
gets promoted.

I don't think that follows at all. There are many scenarios where you'd want the standby to have different permissions than the primary. And I'm not sure it's our business to enforce that. A much much more common mistake people make is run pg_basebackup as the wrong user, thereby getting the wrong owner of all files. But that doesn't mean we should enforce the owner/group of the files.

--
Reply | Threaded
Open this post in threaded view
|

Re: pg_basebackup ignores the existing data directory permissions

Haribabu Kommi-2

On Wed, Feb 20, 2019 at 7:40 PM Magnus Hagander <[hidden email]> wrote:

On Wed, Feb 20, 2019 at 5:17 AM Haribabu Kommi <[hidden email]> wrote:

On Fri, Feb 15, 2019 at 10:15 AM Michael Paquier <[hidden email]> wrote:
On Thu, Feb 14, 2019 at 11:21:19PM +1100, Haribabu Kommi wrote:
> On Thu, Feb 14, 2019 at 8:57 PM Magnus Hagander <[hidden email]> wrote:
>> I think it could be argued that neither initdb *or* pg_basebackup should
>> change the permissions on an existing directory, because the admin may have
>> done that intentionally. But when they do create the directory, they should
>> follow the same patterns.
>
> Hmm, even if the administrator set some specific permissions to the data
> directory, PostgreSQL server doesn't allow server to start if the
> permissions are not (0700) for versions less than 11 and (0700 or
> 0750) for version 11 or later.

Yes, particularly with pg_basebackup -R this adds an extra step in the
user flow.

Perhaps we should make the enforcement of permissions conditional on -R? OTOH that's documented as "write recovery.conf", but we could change that to be "prepare for replication" or something?

Yes, the enforcement of permissions can be done only when -R option is provided.
The documentation is changed in v12 already as "write configuration for replication".
 

> To let the user to use the PostgreSQL server, user must change the
> permissions of the data directory. So, I don't see a problem in
> changing the permissions by these tools.

I certainly agree with the point of Magnus that both tools should
behave consistently, and I cannot actually imagine why it would be
useful for an admin to keep a more permissive data folder while all
the contents already have umasks set at the same level as the primary
(or what initdb has been told to use), but perhaps I lack imagination.
If we doubt about potential user impact, the usual, best, answer is to
let back-branches behave the way they do now, and only do something on
HEAD.

I also agree that both inidb and pg_basebackup should behave same.
Our main concern is that standby data directory that doesn't follow
the primary data directory permissions can lead failures when the standby
gets promoted.

I don't think that follows at all. There are many scenarios where you'd want the standby to have different permissions than the primary.

I really having a hard time to understand that how the different permissions are possible? 
I think of that the standby is having more restrict permissions. May be the standby is not a
hot standby?

Can you please provide some more details? 

Till v11, PostgreSQL  allows the data directory permissions to be 0700 of the directory, otherwise
server start fails, even if the pg_basebackup is successful. In my testing I came to know that data 
directory permissions less than 0700 e.g- 0300 also the server is started. I feel the check of validating
data directory is checking whether are there any group permissions or not? But it didn't whether the
current owner have all the permissions are not? Is this the scenario are you expecting?

 
And I'm not sure it's our business to enforce that. A much much more common mistake people make is run pg_basebackup as the wrong user, thereby getting the wrong owner of all files. But that doesn't mean we should enforce the owner/group of the files.

I didn't understand this point also clearly. The system user who executes the pg_basebackup command,
all the database files are associated with that user. If that corresponding user don't have permissions to
access that existing data folder, the backup fails. 

Regards,
Haribabu Kommi
Fujitsu Australia
Reply | Threaded
Open this post in threaded view
|

Re: pg_basebackup ignores the existing data directory permissions

Peter Eisentraut-6
pg_basebackup copies the data directory permission mode from the
upstream server.  But it doesn't copy the ownership.  So if say the
upstream server allows group access and things are owned by
postgres:postgres, and I want to make a copy for local development and
make a backup into a directory owned by peter:staff without group
access, then it would be inappropriate for pg_basebackup to change the
permissions on that directory.

--
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Reply | Threaded
Open this post in threaded view
|

Re: pg_basebackup ignores the existing data directory permissions

Haribabu Kommi-2

On Fri, Mar 8, 2019 at 11:59 PM Peter Eisentraut <[hidden email]> wrote:
pg_basebackup copies the data directory permission mode from the
upstream server.  But it doesn't copy the ownership.  So if say the
upstream server allows group access and things are owned by
postgres:postgres, and I want to make a copy for local development and
make a backup into a directory owned by peter:staff without group
access, then it would be inappropriate for pg_basebackup to change the
permissions on that directory.

Yes, I agree that it may be a problem if the existing data directory permissions
are 0700 to changing it to 0750. But it may not be a problem for the scenarios,
where the existing data permissions  >=0750, to the upstream permissions.
Because user must need to change anyway to start the server, otherwise server
start fails, and also the files inside the data folder follows the permissions of the
upstream data directory.

usually production systems follows same permissions are of upstream, I don't
see a problem in following the same for development environment also?

comments?

Regards,
Haribabu Kommi
Fujitsu Australia
Reply | Threaded
Open this post in threaded view
|

Re: pg_basebackup ignores the existing data directory permissions

Peter Eisentraut-6
On 2019-03-09 02:19, Haribabu Kommi wrote:

> Yes, I agree that it may be a problem if the existing data directory
> permissions
> are 0700 to changing it to 0750. But it may not be a problem for the
> scenarios,
> where the existing data permissions  >=0750, to the upstream permissions.
> Because user must need to change anyway to start the server, otherwise
> server
> start fails, and also the files inside the data folder follows the
> permissions of the
> upstream data directory.
>
> usually production systems follows same permissions are of upstream, I don't
> see a problem in following the same for development environment also?

I think the potential problems of getting this wrong are bigger than the
issue we are trying to fix.

--
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Reply | Threaded
Open this post in threaded view
|

Re: pg_basebackup ignores the existing data directory permissions

Haribabu Kommi-2

On Fri, Mar 15, 2019 at 10:33 AM Peter Eisentraut <[hidden email]> wrote:
On 2019-03-09 02:19, Haribabu Kommi wrote:
> Yes, I agree that it may be a problem if the existing data directory
> permissions
> are 0700 to changing it to 0750. But it may not be a problem for the
> scenarios,
> where the existing data permissions  >=0750, to the upstream permissions.
> Because user must need to change anyway to start the server, otherwise
> server
> start fails, and also the files inside the data folder follows the
> permissions of the
> upstream data directory.
>
> usually production systems follows same permissions are of upstream, I don't
> see a problem in following the same for development environment also?

I think the potential problems of getting this wrong are bigger than the
issue we are trying to fix.

Thanks for your opinion. I am not sure exactly what are the problems.
But anyway I can go with your suggestion. 

How about changing the data directory permissions for the -R scenario?
if executing pg_basebackup on to an existing data directory is a common
scenario? or leave it?

Regards,
Haribabu Kommi
Fujitsu Australia
Reply | Threaded
Open this post in threaded view
|

Re: pg_basebackup ignores the existing data directory permissions

Robert Haas
In reply to this post by Peter Eisentraut-6
On Thu, Mar 14, 2019 at 7:34 PM Peter Eisentraut
<[hidden email]> wrote:
> I think the potential problems of getting this wrong are bigger than the
> issue we are trying to fix.

I think the question is: how do we know what the user intended?  If
the user wants the directory to be accessible only to the owner, then
we ought to set the permissions on the directory itself and of
everything inside it to 0700 (or 0600).  If they want group access, we
should set everything to 0750 (or 0644).  But how do we know what the
user wants?

Right now, we take the position that the user wants the individual
files to have the same mode that they do on the master, but the
directory should retain its existing permissions.  That appears to be
pretty silly, because that might end up creating a bunch of files
inside the directory that are marked as group-readable while the
directory itself isn't; surely nobody wants that.  Adopting this patch
would fix that inconsistency.

However, it might be better to go the other way.  Maybe pg_basebackup
should decide whether group permission is appropriate for the
contained files and directories not by looking at the master, but by
looking at the directory into which it's writing.  The basic objection
to this patch seems to be that we should not assume that the user got
the permissions on the existing directory wrong, and I think that
objection is fair, but if we accept it, then we should ask why we're
setting the permission of everything under that directory according to
some other methodology.

Another option would be to provide a pg_basebackup option to allow the
user to specify what they intended i.e.  --[no-]group-read.  (Tying it
to -R doesn't sound like a good decision to me.)

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

123