Re: pg_basebackup ignores the existing data directory permissions

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

In response to

Responses

Browse pgsql-hackers by date

  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