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 da...@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
signature.asc
Description: OpenPGP digital signature
