On Thu, Mar 14, 2019 at 7:34 PM Peter Eisentraut <peter.eisentr...@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