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?
> 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.
