Re: PATCH: Configurable file mode mask

David Steele <david(at)pgmasters(dot)net> writes:
> On 3/13/17 2:16 PM, Tom Lane wrote:
>> I also don't especially want to have to analyze cases like "what
>> happens if user initdb'd with mask X but then changes the GUC and
>> restarts the postmaster?". Maybe the right thing is to not expose
>> this as a GUC at all, but drive it off the permissions observed on
>> the data directory at postmaster start. Viz:
>>
>> * $PGDATA has permissions 0700: adopt umask 077
>>
>> * $PGDATA has permissions 0750: adopt umask 027
>>
>> * anything else: fail

> How about a GUC, allow_group_access, that when set will enforce
> permissions and set the umask accordingly, and when not set will follow
> $PGDATA as proposed above?

Seems overcomplicated ...

> Not much we can do for Windows, though. I think it would have to WARN
> if the GUC is set and then continue as usual.

Yeah, the Windows port has been weak in this area all along. I don't
think it's incumbent on you to make it better.

>> That way, a "chmod -R" would be the necessary and sufficient procedure
>> for switching from one case to the other.

> I'm OK with that if you think it's the best course, but perhaps the GUC
> would be better because it can detect accidental permission changes.

If we're only checking file permissions at postmaster start, I think it's
illusory to suppose that we're offering very much protection against
accidental changes. A chmod applied while the postmaster is running
could still break things, and we'd not notice till the next restart.

But it might be worth thinking about whether we want to encourage people
to do manual chmod's at all; that's fairly easy to get wrong, particularly
given the difference in X bits that should be applied to files and
directories. Another approach that could be worth considering is
a PGC_POSTMASTER GUC with just two states (group access or not) and
make it the postmaster's responsibility to do the equivalent of chmod -R
to make the file tree match the GUC. I think we do a tree scan anyway
for other purposes, so correcting any wrong file permissions might not
be much added work in the normal case.

regards, tom lane