* Tom Lane ( wrote:
> Stephen Frost <> writes:
> > Further, the notion that *this* is the footgun is completely off the
> > reservation- if the files have been changed to allow untrusted users to
> > have access to them, there isn't diddly we can do about it.
> I completely disagree that those file-permissions checks are useless.
> What they accomplish is, if you accidentally set up an insecure key file,
> you'll get told about it fairly promptly, and have the opportunity to
> either fix the permissions or generate a new key, depending on your
> opinion of how likely it is that somebody stole the key already.  If we
> made no checks then, more than likely, an insecure key file would just
> sit there indefinitely, waiting for some passing blackhat to grab it.

If that's something you're concerned with then the right answer is to
monitor the file permissions- and there are tools which do exactly that.

I disagree that it's PG's charter to do that and, frankly, you *won't*
be told, in most cases, promptly about such a change.  We don't check
the permissions on every file or even every directory on every query or
even every connection.  With uptimes of days, weeks and months quite
often seen, this idea that PG is protecting you with these checks in
any way is instead creating a false sense of security.

> We can certainly discuss whether we need more than one model of what
> appropriate permissions are, but I do not believe that "rip out the
> check" is a helpful answer.

We're over-claiming what these protections are actually providing.  At
best, they help a new user out when they're first setting up their
database, if they're doing it from source and fully understand how to
correctly set up pg_hba.conf and friends to secure *those*.  Users
installing packages from distributions will have the benefit that the
distribution will get the permissions correct initially and not have to
worry about them.  Permission changes to these files after the system is
set up and running indicate that it's already too late because PG won't
tell the user there's an issue until a DB restart a month or two later,
and by then, if there's an untrusted user who was able to gain access
thanks to such changes, you can be sure they will have.



Attachment: signature.asc
Description: Digital signature

Reply via email to