Re: PATCH: Configurable file mode mask

Michael,

* Michael Paquier (michael(at)paquier(dot)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