On Thu, Mar 14, 2019 at 7:34 PM Peter Eisentraut
<peter.eisentraut@2ndquadrant.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.
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.)
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company