Message-ID: <555CDC56.5050607@agliodbs.com>
Date: Wed, 20 May 2015 12:11:18 -0700
From: Josh Berkus <josh@agliodbs.com>
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: Tom Lane <tgl@sss.pgh.pa.us>,
 Alvaro Herrera <alvherre@2ndquadrant.com>
CC: =?UTF-8?B?Vm9sa2VyIEHDn21hbm4=?= <volker.assmann@gmail.com>,
 Robert Haas <robertmhaas@gmail.com>,
 Stephen Frost <sfrost@snowman.net>, Andrew Dunstan <andrew@dunslane.net>,
 "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: Disabling trust/ident authentication configure option
References: 
 <CAJBpAdwwX8MmHaqMu43YCLJLrpX=1uKAgzpwRBqU8xNX=920Kw@mail.gmail.com>
 <CA+Tgmob4wt1f84k-iYPou1ZtHCwLn=gRApk4i=q8TAwnQjCx+w@mail.gmail.com>
 <CAJBpAdxWQscGEJubs-KLMXYd76tspwD_b2wmgYArsYYTX5ao7w@mail.gmail.com>
 <WM!3b761876ad683334d7afacc13949867067da229b8b4a89a6384ebd101a9ce056b35e6732803f2295acef5787aadcb6e2!@asav-1.01.com>
 <55596375.7070601@agliodbs.com>
 <CAJBpAdzUeVqJ1R+0V_Eg8+Z0HdrHYq7HHx+a4q1BT9-h9Yvoiw@mail.gmail.com>
 <CB1A1AB6-B345-4ED7-A705-D87E4DC99E11@gmail.com>
 <CAJBpAdzH3pMTFfBE+dYd+OytVJXR2XF=ESQ7TG6syjB1suh2ZQ@mail.gmail.com>
 <WM!22b0c9d0d605588edea2c700c71c4e0b51033b37a1185be38d4160d6de08c76eba51fd2754a9d1446b4cfb3fccceb9ce!@asav-2.01.com>
 <555CC5DE.3050707@agliodbs.com> <20150520175916.GB5885@postgresql.org>
 <23809.1432145430@sss.pgh.pa.us>
 <WM!6a10d1d9bf3d237078cee58af8aba8eb1f4eb065a68f02eece6d9cc0dfc8c8357d255d0f6f5ccadf019b03dbf1877c5d!@asav-2.01.com>
In-Reply-To: 
 <WM!6a10d1d9bf3d237078cee58af8aba8eb1f4eb065a68f02eece6d9cc0dfc8c8357d255d0f6f5ccadf019b03dbf1877c5d!@asav-2.01.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On 05/20/2015 11:10 AM, Tom Lane wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
>> Josh Berkus wrote:
>>> As such, proposals are more likely to be successful if the proposer can
>>> show how they apply to a general use case, or adapt them so that they
>>> are useful to a large number of our users.  This means that "this works
>>> in our environment which has conditions X, Y, and Z" is not an effective
>>> argument, unless you can follow it up with "... and here's the reason
>>> why [large class of users] also has conditions X, Y and Z."
> 
>> The proposal here is to have a configure argument that disables
>> arbitrary auth mechanisms.  How is that specific to a particular
>> environment?
> 
> I think Josh's question is whether the feature is actually useful to
> a large class of users.
> 
> One reason why it would not be, if it's a build-time decision,
> is that it's quite unlikely that any popular packagers would build
> that way.  So this would only be applicable to custom-built binaries,
> which is a pretty small class of users to begin with.

Precisely.

My second point is that it's not useful for the reason Volker says it
is; that is, it simply doesn't protect against "lazy admin mistakes",
*and* there are already other mechanisms in the world of IT which do a
better job of this (primarily, centralized configuration management).

I am aware of a large group of users who are concerned with lock-down
security and do custom builds: the makers of security appliances, many
or most of whom use PostgreSQL as a database.  However, those vendors
also lock down access to pg_hba.conf and postgresql.conf, so a
compile-time option is of, at best, marginal use to them.  Stretching my
imagination over the different types of PostgreSQL users I know, I can't
actually think of any who, as a group, would make use of this feature.

So the first thing to establish is "other than Volker himself, who are
we helping here?"

The second major issue I have is that it's an anti-security feature.
That is, it ignores the several ways in which someone with superuser
access can bypass the lack of an auth mechanism, while giving anyone who
installs the option a false sense of safety.  Ineffective security
measures lead to worse security holes than being aware that you're at risk.

-- 
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