From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com> |
Cc: | Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: pg_basebackup ignores the existing data directory permissions |
Date: | 2019-02-14 23:15:24 |
Message-ID: | 20190214231524.GC2240@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Gierth | 2019-02-14 23:28:39 | Re: Ryu floating point output patch |
Previous Message | Michael Paquier | 2019-02-14 23:08:54 | Re: [Suspect SPAM] Better error messages when lacking connection slots for autovacuum workers and bgworkers |