Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1ii8XE-0000OB-UH for pgsql-pkg-yum@arkaria.postgresql.org; Fri, 20 Dec 2019 03:01:01 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1ii8XD-0006yE-Ng for pgsql-pkg-yum@arkaria.postgresql.org; Fri, 20 Dec 2019 03:00:59 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1ii8XD-0006y5-Be for pgsql-pkg-yum@lists.postgresql.org; Fri, 20 Dec 2019 03:00:59 +0000 Received: from mail-lj1-x231.google.com ([2a00:1450:4864:20::231]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1ii8XA-0003wk-3A for pgsql-pkg-yum@lists.postgresql.org; Fri, 20 Dec 2019 03:00:58 +0000 Received: by mail-lj1-x231.google.com with SMTP id e28so8424968ljo.9 for ; Thu, 19 Dec 2019 19:00:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AlXKDP6S98kCJu7PrCKYMXTh7ykFEP49xQBrq07nzqM=; b=KuNli7nZ6s1IKHPvmuVp3/aDTsi2Yv1nikiHDhocGUUgXinRcZUPba/qXzemQ1Fo6v dH3Gdm4Hr5gZRz8rMLhi75Si/uc40snjzyyAF9wPjpJgP+jBmagJ5dRiCsXyN4/8RzJg lD9EyeaE0/9aqDdp4Mk/atwETk5rXE+kBlBFj+VEIPxtagKiPgIg2bQUyYdG1vT4OvZz 7ETv78/gcoJnTeOykF34ACypVVuUgsors5qRI2HVxb5X3P3VSXpWXNv0t+tRpLzyEgJc 7zNyUW9szLUXjx2oV1/z1/SdMGlvMMpO3A62ewINwB38vkd0JvkQVkan8PspUyJRFzS0 4s0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AlXKDP6S98kCJu7PrCKYMXTh7ykFEP49xQBrq07nzqM=; b=jmIh/o68ucqHClICHYYctPyJp4HIAo5eyKEyWjWBTaZNjXqHIbSBLyPouqT5WCxAWe lAdIYVjQkw5ZiqcWppOVrx/5B+87zrZEZRrrWp3smZ3zlqQ1l22o6RUI05oCAdXIQVkW 2AcEwmpnr5btQhCgPpBBPXz7L0gRBG0nIaz+4yEw6XzFB7uWrhMP1mD+vduR3s0w1dgw iEj/KCunm02n3pZqYA93d+l4ZcXiZTVOLTRjz6SDCvFK3G3JH37LCJ9tcBUtBouyzcJR nUlI/BfqT6LHQUdr1aMqnsnMw1LcIGt3zgEUOkIgw13vUn8/sdkkgE/OX7rJhZ+PGr9O BtzA== X-Gm-Message-State: APjAAAUkYraIzSIOFlkEidHuajv7TQL9qLki9+2NDeGsdrShmDOS6L1F gWNdvtmaLPCsB/bwcPEEPy58+X2twgA7HZ0ZcDuggToSDZ4= X-Google-Smtp-Source: APXvYqxk1beSETzAxTpDiZlPVY4m2o46YnV+bcdSuzqehYOhEHD8rzVLurR60J2QFt8H/q9OY1/Oz2qKxc18a05/koQ= X-Received: by 2002:a2e:7816:: with SMTP id t22mr8290609ljc.161.1576810855340; Thu, 19 Dec 2019 19:00:55 -0800 (PST) MIME-Version: 1.0 References: <83bdce65-302f-49ef-828a-3831fe11d904@www.fastmail.com> <20191219165719.GC3195@tamriel.snowman.net> <02c6c7de-e2e2-48cd-94e7-7d65b7196ca5@www.fastmail.com> <20191219173228.GF3195@tamriel.snowman.net> In-Reply-To: From: Craig Ringer Date: Fri, 20 Dec 2019 11:00:43 +0800 Message-ID: Subject: Re: Can we stop defaulting to 'ident'? To: James Cassell Cc: PostgreSQL Yum Package List Content-Type: multipart/alternative; boundary="000000000000e93d0f059a19e25d" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --000000000000e93d0f059a19e25d Content-Type: text/plain; charset="UTF-8" On Fri, 20 Dec 2019 at 05:08, James Cassell 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@#$ 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@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 --000000000000e93d0f059a19e25d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, 20 Dec 2019 at 05:08, James Casse= ll <fedoraproject@cyberpe= ar.com> wrote:

I fail to see how ident over TCP is insecure when used on the localhost add= ress. Can you explain? Otherwise, is there a way to make peer authenticatio= n work with TCP connections?

ident is s= ecure (or as secure as 'peer' for unix sockets) over TCP/IP loopbac= k connections. But pretty much only then or on networks that you totally co= ntrol all hosts on and all access to.

To spoof ide= nt 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 n= onfunctional without additional services that the rpms do not depend on= . It actively gets in the way of users since they cannot then simply
<= div>
=C2=A0 =C2=A0 CREATE USER foo WITH PASSWORD 'bar'= ;;

and connect. They have to go in and unf@#$ our = generated pg_hba.conf too.

So if you like ident, f= ine. That's not a problem. You can

=C2=A0 =C2= =A0=C2=A0/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 v= s the Debian packages to add to user confusion.

= =C2=A0 =C2=A0 [craig@ayaki] $ psql -h localhost
=C2=A0 =C2=A0 psql: erro= r: could not connect to server: FATAL: =C2=A0Ident authentication failed fo= r user "craig"

"WOT?"

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

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

=C2=A0 =C2=A0 /usr/pgsql-12/bin/p= ostgresql-12-setup -A md5
=C2=A0
be doing

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

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

--
=C2=A0Craig= Ringer=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://www.2ndQuadrant.com/
=C2=A02ndQuadr= ant - PostgreSQL Solutions for the Enterprise
--000000000000e93d0f059a19e25d--