Re: pg_basebackup ignores the existing data directory permissions - Mailing list pgsql-hackers
From | Haribabu Kommi |
---|---|
Subject | Re: pg_basebackup ignores the existing data directory permissions |
Date | |
Msg-id | CAJrrPGdmDLWFC-T2U=M7qXwoFAx09AuBF04Ww1i3aNzgWOGCsQ@mail.gmail.com Whole thread Raw |
In response to | Re: pg_basebackup ignores the existing data directory permissions (Magnus Hagander <magnus@hagander.net>) |
Responses |
Re: pg_basebackup ignores the existing data directory permissions
|
List | pgsql-hackers |
On Wed, Feb 20, 2019 at 7:40 PM Magnus Hagander <magnus@hagander.net> wrote:
On Wed, Feb 20, 2019 at 5:17 AM Haribabu Kommi <kommi.haribabu@gmail.com> wrote:On Fri, Feb 15, 2019 at 10:15 AM Michael Paquier <michael@paquier.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@hagander.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 followthe primary data directory permissions can lead failures when the standbygets 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.
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
pgsql-hackers by date: