Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1YuCCe-0006v1-VT for pgsql-hackers@arkaria.postgresql.org; Mon, 18 May 2015 03:58:57 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1YuCCe-0002sh-9t for pgsql-hackers@arkaria.postgresql.org; Mon, 18 May 2015 03:58:56 +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 1YuCCb-0002sY-VP for pgsql-hackers@postgresql.org; Mon, 18 May 2015 03:58:54 +0000 Received: from mx-out.zmailcloud.com ([192.198.85.98] helo=mx-out-1.zmailcloud.com) by magus.postgresql.org with esmtp (Exim 4.84) (envelope-from ) id 1YuCCX-0003DN-OY for pgsql-hackers@postgresql.org; Mon, 18 May 2015 03:58:53 +0000 Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 94958563E95; Sun, 17 May 2015 22:58:48 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 7E520A0306; Sun, 17 May 2015 22:58:48 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Qfg0sAYTeBG; Sun, 17 May 2015 22:58:48 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 4707CA031A; Sun, 17 May 2015 22:58:48 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 1E617A030A; Sun, 17 May 2015 22:58:48 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id GfgohkW0jeah; Sun, 17 May 2015 22:58:48 -0500 (CDT) Received: from [192.168.47.108] (50-0-164-123.dsl.dynamic.fusionbroadband.com [50.0.164.123]) by smtp-out-1.01.com (Postfix) with ESMTPSA id 168B4A0306; Sun, 17 May 2015 22:58:46 -0500 (CDT) Message-ID: <55596375.7070601@agliodbs.com> Date: Sun, 17 May 2015 20:58:45 -0700 From: Josh Berkus Organization: PostgreSQL Experts Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: =?UTF-8?B?Vm9sa2VyIEHDn21hbm4=?= CC: Stephen Frost , Tom Lane , Andrew Dunstan , Alvaro Herrera , "pgsql-hackers@postgresql.org" Subject: Re: Disabling trust/ident authentication configure option References: <20150506144724.GU2523@alvh.no-ip.org> <554A720F.1030706@dunslane.net> <554A797B.1010101@dunslane.net> <6837.1430946793@sss.pgh.pa.us> <554A9898.9040407@agliodbs.com> <20150507150254.GA30322@tamriel.snowman.net> <20150507205749.GE30322@tamriel.snowman.net> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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 Wed, May 13, 2015 at 2:18 PM, Robert Haas > wrote: > 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. So, I'm going to throw in why a configure option to disable "trust, peer" is an unworkable idea. The goal here was stated to preventing authentication misconfiguration by shortsighted admins who have superuser access and the ability to change pg_hba.conf. This is tantamount to giving someone a gun and bullets, but expecting duct tape across the cartridge slot to prevent them from loading or using the gun. Let's say we offered a compile-time option, and then someone built a package postgresql-9.6-secureauth.deb. So, your lazy admin is having trouble debugging an auth problem and wants to set "trust". But they can't. So they search on Google and figure out how to download and install postgresql-9.6-normalauth.deb. Or, alternately, they set all passwords to "password" or to "". Or they put .pgpass files on all machines. Or they put the password in pgbouncer and set pgbouncer to "trust". You've added exactly one additional step in their way, and not a particularly difficult one. It simply doesn't solve the problem you're trying to solve, which is unsurprising, because technology has never been able to solve the problem of untrustworthy humans with positions of responsibility. Now, if you wanted to add an audit log every time someone changes an auth method in pg_hba.conf? I'd be all for that, I can see all kinds of uses for that, and it might actually accomplish something effective. If you disagree with me, well, it would be very easy to hack out the auth methods you don't like and compile your own. It *is* open source. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers