On 3/13/18 2:46 AM, Michael Paquier wrote:
> On Mon, Mar 12, 2018 at 03:14:13PM -0400, Stephen Frost wrote:
>> We already had a discussion about having a GUC for this and concluded,
>> rightly in my view, that it's not sensible to have since we don't want
>> all of the various tools having to read and parse out postgresql.conf.
>
> If the problem is parsing, it could as well be more portable to put that
> in the control file, no?
The current approach is based on early discussion of this patch, around
[1] and [2] in particular. I proposed an enforcing GUC at that time but
there wasn't any interest in the idea.
I definitely think it's overkill to put a field in pg_control as that
requires more tooling to update values.
>> I don't see anything in the discussion which has changed that and I
>> don't agree that there's an issue with using the privileges on the data
>> directory for this- it's a simple solution which all of the tools can
>> use and work with easily. I certainly don't agree that it's a serious
>> issue to relax the explicit check- it's just a check, which a user could
>> implement themselves if they wished to and had a concern for. On the
>> other hand, with the explicit check, we are actively preventing an
>> entirely reasonable goal of wanting to use a read-only role to perform a
>> backup of the system.
>
> Well, one thing is that the current checks in the postmaster make sure
> that a data folder is never using anything else than 0700. From a
> security point of view, making it possible to allow a postmaster to
> start with 0750 is a step backwards if users don't authorize it
> explicitely.
I would argue that changing the mode of PGDATA is explicit, even if it
is accidental. To be clear, after a pg_upgrade the behavior of the
cluster WRT to setting the mode would be exactly the same as now. The
user would need to specify -g at initdb time or explicitly update PGDATA
to 750 for group access to be enabled.
> There are a lot of systems which use a bunch of users with
> only single group with systemd. So this would remove an existing
> safeguard. I am not against the idea of this thread, just that I think
> that secured defaults should be user-enforceable if they want Postgres
> to behave so.
As Stephen notes, this can be enforced by the user if they want to, and
without much effort (and with better tools).
Regards,
--
-David
david@pgmasters.net
[1] https://www.postgresql.org/message-id/20526.1489428968%40sss.pgh.pa.us
[2] https://www.postgresql.org/message-id/22248.1489431803%40sss.pgh.pa.us
