Re: pg_basebackup ignores the existing data directory permissions

On Wed, Feb 20, 2019 at 7:40 PM Magnus Hagander <magnus(at)hagander(dot)net> wrote:

>
> On Wed, Feb 20, 2019 at 5:17 AM Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>
> wrote:
>
>>
>> On Fri, Feb 15, 2019 at 10:15 AM Michael Paquier <michael(at)paquier(dot)xyz>
>> 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 <magnus(at)hagander(dot)net>
>>> 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