Re: PATCH: Configurable file mode mask

On 3/13/17 3:03 PM, Tom Lane wrote:
> 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 ...

Yeah. It wouldn't be a lot of fun to document, that's for sure.

>>> 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.

Fair enough.

> 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.

The majority of scanning is done in recovery (to find and remove
unlogged tables) and I'm not sure we would want to add that overhead to
normal startup.

--
-David
david(at)pgmasters(dot)net