On Wed, May 13, 2015 at 8:01 AM, Volker Aßmann <volker.assmann@gmail.com> wrote:
> Even in this case it still means that any breach in any of the network
> services running on your application server would immediately own your
> database, or at least everything your application can access. This applies
> even to totally unrelated services running with restricted permissions.
> Using password or certificate based authentication at least gives you the
> additional security of local filesystem access controls and is not much
> harder to setup. M2M authentication is always a difficult topic as the
> "authentication tokens" have to be secured but I would agree that a more
> specific / secure method than "disable-all-authentication" would be
> preferable.
Sure, opinions on the best way to do any given thing are going to
vary, and nobody's trying to prevent you from configuring your
instances of PostgreSQL however you like. The email to which I was
responding was suggesting limiting MY ability to set up MY instances
of PostgreSQL the way I like. And I'm opposed to that.
All of this is fairly far afield from the original topic of this
thread, which was whether a configure option disabling trust + ident
authentication would be a good idea. I said no. Then we had a bunch
of counter-proposals:
Alvaro: Support a configure switch whose value is a comma-separated
list of authentication methods to disable.
Peter: Generalized hardening facility.
Andrew: Like what Alvaro said, but require at least one of trust +
peer to remain enabled so people can't hose themselves.
Andrew, v2: Rip out RFC1413 ident authentication completely.
Stephen: Require a command-line option to use trust auth.
There's clearly no consensus on any of these proposals, and most of
them don't address your original requirement anyway, though Alvaro's
would. I guess the point is that nothing is going to get changed
here on one person's say-so if other people don't agree, so if you
want to get something done, you're going to need to pick something
that can achieve consensus and then implement that. Also, anything
you want to get done is certainly going to be in 9.6 at the earliest,
because the time for 9.5 proposals has already come and gone.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
