Re: Disabling trust/ident authentication configure option

* Josh Berkus (josh(at)agliodbs(dot)com) wrote:
> On 05/20/2015 11:10 AM, Tom Lane wrote:
> > Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> >> 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.

I do not agree with the 'quite unlikely' characterization. We would
need to make a case to them as to why there are better options than
having 'trust' be supported, but that only makes sense once there *are*.
We know there are reasons we need it today and there's not much point
having this discussion until those have been addressed.

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

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

I don't believe this is correct. Your definition of an anti-security
feature is fine, but I don't agree with the assumption that people will
feel secure because 'trust' isn't compiled in.

Most users are unlikely to notice it's gone and the argument you're
making here is that the users who will be upset that it's no longer
available are all knowledgable enough to realize when it's valid to
use. I seriously doubt that's the case and throwing a big warning in
front of them saying "trust is no longer built-in because it's a big
glaring security hole, please use another mechanism" would hopefully
get them to understand why it was an issue, why it shouldn't be used,
and what options are available and what their tradeoffs are.

I still don't believe there's much point in the discussion until there
are viable alternatives for the use-cases where we really need to be
able to just get into PG and get data out quickly in the face of
corruption, but I wanted to share my disagreement regarding the
assumption that packagers would never consider disabling 'trust'.

Thanks!

Stephen