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