Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Yq3Yi-0007bv-Dq for pgsql-hackers@arkaria.postgresql.org; Wed, 06 May 2015 17:56:36 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1Yq3Yh-0007Sy-U8 for pgsql-hackers@arkaria.postgresql.org; Wed, 06 May 2015 17:56:35 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1Yq3Yh-0007Ss-51 for pgsql-hackers@postgresql.org; Wed, 06 May 2015 17:56:35 +0000 Received: from mout.gmx.net ([212.227.17.22]) by magus.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.84) (envelope-from ) id 1Yq3Yd-0007jm-SE for pgsql-hackers@postgresql.org; Wed, 06 May 2015 17:56:34 +0000 Received: from auth1-smtp.messagingengine.com ([66.111.4.227]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MBaDy-1YzRE30mxS-00AV5L for ; Wed, 06 May 2015 19:56:29 +0200 Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailauth.nyi.internal (Postfix) with ESMTP id 6F45320B63 for ; Wed, 6 May 2015 13:56:27 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Wed, 06 May 2015 13:56:27 -0400 X-Sasl-enc: WNxt2734A9se3Uo/7crM8X1jiAevk2ypdktVIe3ZlpmF 1430934987 Received: from [192.168.1.147] (unknown [204.145.120.11]) by mail.messagingengine.com (Postfix) with ESMTPA id 37BB26800FA; Wed, 6 May 2015 13:56:27 -0400 (EDT) Message-ID: <554A55CA.5000705@gmx.net> Date: Wed, 06 May 2015 13:56:26 -0400 From: Peter Eisentraut User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: =?UTF-8?B?Vm9sa2VyIEHDn21hbm4=?= , Robert Haas CC: "pgsql-hackers@postgresql.org" Subject: Re: Disabling trust/ident authentication configure option References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:bIRJtvJF511FqIkL87quhdPkDgzd7ZjU1k3s+Zg8znhD6Xq5kYE xjesl8L8rJbapCUaWZ0lYgHD/8wfANuP0hAf4EiaJVKUug9bRjCUZlqW9v1PtoDzkq58TGv JsxT7Gie6TIK4HgqxXS0Q8VroU+1Y68NMmYhW+LbSANGPZjTtijGk54nAMwXBJzGEgEviHj 0t7AIc/gvLrQCZQ267Auw== X-UI-Out-Filterresults: notjunk:1; X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org On 5/6/15 6:02 AM, Volker Aßmann wrote: > Well "trust" actually does not sound that dangerous in case you only > take a quick glance at the documentation - "trust PostgreSQL to do the > right thing?" Hah, we could rename it to "wideopen". > Please note that the patch does nothing by default, it just adds the > option to disable trust/ident but leaves them on in the standard > configuration. I do not want to disable "trust" by default for everyone, > but it would be great to have the option to do this without having to > patch (and thus test and verify) the PostgreSQL sources for each new > release. Any new compile-time option creates a nonlinear maintenance burden. We're going to need to test whether each option builds cleanly and works, also in combination with other options, and on several platforms. The authentication code is already littered with build-time dependencies and platform-specific code. So the "it doesn't bother anyone" argument doesn't quite work. Actually, in this particular case, you wouldn't even need a compile-time option. You could just make it a restart-only option. > I think this is a sufficiently general requirement to warrant including > an option to disable this, as most hardening guides I have seen for > PostgreSQL unconditionally require to disable trust authentication and > disabling it in the code removes the need to check this in the runtime > configuration. I think people would be interested in well-thought out, generalized hardening facilities. But that would likely include other things than just disabling an authentication method or two. And we can't be adding a new compile-time option as we add each one. We need a more general approach. > Single user sessions would work, but the "peer" authentication is also > still available and should be the preferred method to reset passwords > when trust is disabled, so this should not be an issue. "peer" authentication is unfortunately not quite portable. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers