Michael, * Michael Paquier (mich...@paquier.xyz) 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? 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.
Then we'd need a tool to allow changing it for people who do want to change it. There's no reason we should have to have an extra tool for this- an administrator who chooses to change the privileges on the data folder should be able to do so and I don't think anyone is going to thank us for requiring them to use some special tool to do so for PostgreSQL. > > 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. I'm aware of what the current one-time check in the postmaster does, and that we don't implement it on all platforms, making me seriously doubt that the level of concern being raised here makes sense. Should we consider it a security issue that the Windows builds don't perform this check, and never has? Further, if the permissions are changed without authorization, it's probably done while the database is running and unlikely to be noticed for days, weeks, or longer, if the administrator is depending on PG to let them know of the change. Considering that the only user who can change the privileges is a database owner or root, it seems even less likely to help (why would an attacker change those privileges when they already have full access?). Lastly, the user *is* able to enforce the privileges on the data directory if they wish to, using tools such as tripwire which are built specifically to provide such checks and to do so regularly instead of the extremely ad-hoc check provided by PG. PostgreSQL should, and does, secure the data directory when it's created by initdb, and subsequent files and directories are similairly secured appropriately. Ultimately, the default which makes sense here isn't a one-size-fits-all but is system dependent and the administrator should be able to choose what permissions they want to have. Thanks! Stephen
signature.asc
Description: PGP signature
