Re: pg_basebackup ignores the existing data directory permissions

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pg_basebackup ignores the existing data directory permissions
Date: 2019-03-18 07:32:44
Message-ID: CABUevEzRkc4P6Eyccn7cQ9+oXjMv8nqVP6GCZqCJi0zLKaE2Jw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Mar 18, 2019 at 7:08 AM Stephen Frost <sfrost(at)snowman(dot)net> wrote:

> Greetings,
>
> * Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> > On Thu, Mar 14, 2019 at 7:34 PM Peter Eisentraut
> > <peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
> > > I think the potential problems of getting this wrong are bigger than
> the
> > > issue we are trying to fix.
> >
> > I think the question is: how do we know what the user intended? If
> > the user wants the directory to be accessible only to the owner, then
> > we ought to set the permissions on the directory itself and of
> > everything inside it to 0700 (or 0600). If they want group access, we
> > should set everything to 0750 (or 0644). But how do we know what the
> > user wants?
> >
> > Right now, we take the position that the user wants the individual
> > files to have the same mode that they do on the master, but the
> > directory should retain its existing permissions. That appears to be
> > pretty silly, because that might end up creating a bunch of files
> > inside the directory that are marked as group-readable while the
> > directory itself isn't; surely nobody wants that. Adopting this patch
> > would fix that inconsistency.
> >
> > However, it might be better to go the other way. Maybe pg_basebackup
> > should decide whether group permission is appropriate for the
> > contained files and directories not by looking at the master, but by
> > looking at the directory into which it's writing. The basic objection
> > to this patch seems to be that we should not assume that the user got
> > the permissions on the existing directory wrong, and I think that
> > objection is fair, but if we accept it, then we should ask why we're
> > setting the permission of everything under that directory according to
> > some other methodology.
>
> Going based on the current setting of the directory seems defensible to
> me, with the argument of "we trust you created the directory the way you
> want the rest of the system to be".
>

Which I believe is also how a plain unix cp (or tar or whatever) would
work, isn't it? I think that alone is a pretty strong reason to work the
same as those -- they're not entirely unsimilar.

> Another option would be to provide a pg_basebackup option to allow the
> > user to specify what they intended i.e. --[no-]group-read. (Tying it
> > to -R doesn't sound like a good decision to me.)
>
> I definitely think that we should add an option to allow the user to
> tell us explicitly what they want here, even if we also go based on what
> the created directory has (and in that case, we should make everything,
> including the base directory, follow what the user asked for).
>

+1 for having an option to override whatever the default is.

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2019-03-18 07:34:03 Re: Online verification of checksums
Previous Message Matsumura, Ryo 2019-03-18 07:31:51 RE: SQL statement PREPARE does not work in ECPG