Re: [HACKERS] PATCH: Configurable file mode mask - Mailing list pgsql-hackers

From David Steele
Subject Re: [HACKERS] PATCH: Configurable file mode mask
Date
Msg-id 1363972f-4245-d4b1-f89b-478c35690f26@pgmasters.net
Whole thread Raw
In response to Re: [HACKERS] PATCH: Configurable file mode mask  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] PATCH: Configurable file mode mask  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 3/13/17 2:16 PM, Tom Lane wrote:
> David Steele <david@pgmasters.net> writes:
>> On 3/13/17 1:03 PM, Tom Lane wrote:
>>> TBH, the fact that we're relying on 0600 mode for considerations such
>>> as these makes me tremendously afraid of this whole patch.  I think that
>>> the claimed advantages are not anywhere near worth the risk that somebody
>>> is going to destroy their database because we weakened some aspect of the
>>> protection against starting multiple postmasters in a database directory.
> 
>> I don't see a risk if the user uses umask 0027 which is the example
>> given in the docs.  I'm happy to change this example to a strong
>> recommendation.

<...>

> Anyway, given that we do that analysis, I'd rather not expose this
> as a "here, set the umask you want" variable.  I think a bool saying
> "allow group access" (translating to exactly two supported umasks,
> 027 and 077) would be simpler from the user's standpoint and much
> easier to reason about.  I don't see the value in having to think
> about what happens if the user supplies a mask like 037 or 067.

We debated a flag vs a umask and came down on the side of flexibility.
I'm perfectly happy with using a flag instead.

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

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.

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

-- 
-David
david@pgmasters.net



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: [HACKERS] Radix tree for character conversion
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Performance improvement for joins where outer side is unique