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

From Tom Lane
Subject Re: [HACKERS] PATCH: Configurable file mode mask
Date
Msg-id 20526.1489428968@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] PATCH: Configurable file mode mask  (David Steele <david@pgmasters.net>)
Responses Re: [HACKERS] PATCH: Configurable file mode mask  (David Steele <david@pgmasters.net>)
List pgsql-hackers
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.

I do not want a "strong recommendation".  I want "we don't let you
break this".  We don't let you run the postmaster as root either,
even though there have been repeated requests to remove that safety
check.

It might be all right if we forcibly or'd 027 into whatever umask
the user tries to provide; not sure.  The existing safety analysis,
such as the cited comment, has all been based on the assumption of
file mode 600 not mode 640.  I'm not certain that we always attempt
to open-for-writing files that we expect to be exclusively accessible
by the postmaster.

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.

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

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



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: [HACKERS] Bogus tab completion tweak for UPDATE ... SET ... =
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Bogus tab completion tweak for UPDATE ... SET ... =