Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1YvC7p-0007BO-3F for pgsql-hackers@arkaria.postgresql.org; Wed, 20 May 2015 22:06:05 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1YvC7o-00083d-94 for pgsql-hackers@arkaria.postgresql.org; Wed, 20 May 2015 22:06:04 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1YvC7m-00083V-Or for pgsql-hackers@postgresql.org; Wed, 20 May 2015 22:06:02 +0000 Received: from mail-qk0-f180.google.com ([209.85.220.180]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84) (envelope-from ) id 1YvC7f-00054V-U1 for pgsql-hackers@postgresql.org; Wed, 20 May 2015 22:06:01 +0000 Received: by qkgx75 with SMTP id x75so41621628qkg.1 for ; Wed, 20 May 2015 15:05:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=GSQH3ySEK8A65PdEtutv+cSCeB5lnmlgsEyYcjONt0M=; b=QMkovr8mhRsdyECnwZVQn/MGnWGFVv9K0FDgCv/xH3Lgv5he95GvNaCNHBu3RHsSCl CVFh7GWzEP3s/VYgHspRUb7vy992C5LXgNw/GrKdRZlLjWbj0hJ4Pu0CXhs7xZnLHBbw tE1l7ZioDZqPmgvL1bWAirXJItBF2ZwjA4rxqjEQ7ULJOB/FrQb6kiIwM8TBWZTGY0Hn Yf7lqF7F1uwVNmxMPOLIKEWntcqPUFcAoHL0aPKc0/qiRKBaW087n18qZCXyU5Vy0K8+ rhUaWwWBfowgIah3PE3Zjh1ZVF6Snf9M0U//lvgNSy+wY7tX5uOU8seFkv8BWW3JRP9F xivQ== X-Gm-Message-State: ALoCoQlUOjx6s6Z4SYyewcYmLU5F/S+H1ms+Kn0pTyyw6A1bwNfpaY6cvagQKj84cZTIRSxlmu2e X-Received: by 10.140.146.22 with SMTP id 22mr11409513qhs.44.1432159555297; Wed, 20 May 2015 15:05:55 -0700 (PDT) Received: from alvin.alvh.no-ip.org ([200.85.219.137]) by mx.google.com with ESMTPSA id g34sm12031034qgd.0.2015.05.20.15.05.54 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 May 2015 15:05:54 -0700 (PDT) Received: by alvin.alvh.no-ip.org (Postfix, from userid 1000) id A81EB200; Wed, 20 May 2015 19:05:41 -0300 (CLT) Date: Wed, 20 May 2015 19:05:41 -0300 From: Alvaro Herrera To: Andres Freund Cc: Stephen Frost , Josh Berkus , Tom Lane , Volker =?iso-8859-1?Q?A=DFmann?= , Robert Haas , Andrew Dunstan , "pgsql-hackers@postgresql.org" Subject: Re: Disabling trust/ident authentication configure option Message-ID: <20150520220541.GJ5885@postgresql.org> References: <555CC5DE.3050707@agliodbs.com> <20150520175916.GB5885@postgresql.org> <23809.1432145430@sss.pgh.pa.us> <555CDC56.5050607@agliodbs.com> <20150520194223.GM26667@tamriel.snowman.net> <20150520215444.GR27868@alap3.anarazel.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20150520215444.GR27868@alap3.anarazel.de> User-Agent: Mutt/1.5.23 (2014-03-12) X-Pg-Spam-Score: -2.6 (--) 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 Andres Freund wrote: > On 2015-05-20 15:42:23 -0400, Stephen Frost wrote: > > > So the first thing to establish is "other than Volker himself, who are > > > we helping here?" > > > > I don't agree with this either. Providing a "bypass all authentication" > > configuration option really isn't a good thing. Why don't packagers use > > our default pg_hba.conf? Because it only makes sense in a development > > type of environment. I'd argue the same is true for 'trust'. > > Uh. So if the shit hit the fan because you mismanaged a password > rollover, kereberos is down, or something like that, and you can't > access postgres anymore you want to recompile? Yeah, it's pretty messy. I thought about providing the feature without involving configure: say have a file listing allowed auth methods; in Volker's case it's easy to ship packages were trust/peer are removed in the file. If you're in deep trouble just enable trust there and fix it. But this has the exact problem we started with: the lazy admin will just enable it "momentarily" to get the thing running and forget to turn it off later. I was thinking that another use for this would be cases where an auth method is found to be insecure and you want to disable it completely (say Kerberos is cracked irreparably or whatever). But the real solution to that problem is to remove it from pg_hba.conf. In the end, it seems there is no actual hole being solved here that cannot be better attacked by other means. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers