Re: Can we stop defaulting to 'ident'?

On Fri, 20 Dec 2019 at 05:08, James Cassell <fedoraproject(at)cyberpear(dot)com>
wrote:

>
> I fail to see how ident over TCP is insecure when used on the localhost
> address. Can you explain? Otherwise, is there a way to make peer
> authentication work with TCP connections?
>

ident is secure (or as secure as 'peer' for unix sockets) over TCP/IP
loopback connections. But pretty much only then or on networks that you
totally control all hosts on and all access to.

To spoof ident you must be able to open a listening socket on a privileged
port on the loopback host. So you need superuser privileges or the
CAP_NET_BIND_SERVICE capability which must be explicitly granted.

I am not arguing for ident to be removed. I'm arguing for it to stop being
the default for rpm package initdb, since it's *totally useless and
nonfunctional without additional services that the rpms do not depend on*.
It actively gets in the way of users since they cannot then simply

CREATE USER foo WITH PASSWORD 'bar';

and connect. They have to go in and unf(at)#$ our generated pg_hba.conf too.

So if you like ident, fine. That's not a problem. You can

/usr/pgsql-12/bin/postgresql-12-setup -A ident

and nothing else changes for you. But it's a really obsolete and unhelpful
default, and it's also one that adds yet another difference vs the Debian
packages to add to user confusion.

[craig(at)ayaki] $ psql -h localhost
psql: error: could not connect to server: FATAL: Ident authentication
failed for user "craig"

"WOT?"

Now, we're hardly going to depend on the ident service in the packages.
It's a security policy violation in many places to even run it. So we
should change the default - probably to scram-sha-256 on pg11 and pg12, and
md5 on older releases.

The only BC implication I can see is that someone's scripts might, rather
than invoking

/usr/pgsql-12/bin/postgresql-12-setup -A md5

be doing

/usr/pgsql-12/bin/postgresql-12-setup
sed -i 's/ident/md5/g' /var/lib/pgsql/12/data/pg_hba.conf

or the like. But I don't think that's a big concern: it's an easy fix, only
affects new initdb's, and is sufficient to cover in the 'news' section +
changelog.

--
Craig Ringer http://www.2ndQuadrant.com/
2ndQuadrant - PostgreSQL Solutions for the Enterprise