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? I have finished for example finished by implementing my own flavor of pg_controldata to save parsing efforts soas it prints control file fields on a per-call basis using individual fields, which saved also games with locales for as translations of pg_controldata can disturb the parsing logic. > 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. 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. -- Michael
signature.asc
Description: PGP signature
