On 05/20/2015 11:10 AM, Tom Lane wrote: > Alvaro Herrera <alvhe...@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
