On 5/6/15 6:02 AM, Volker Aßmann wrote:
> Well "trust" actually does not sound that dangerous in case you only
> take a quick glance at the documentation - "trust PostgreSQL to do the
> right thing?"
Hah, we could rename it to "wideopen".
> Please note that the patch does nothing by default, it just adds the
> option to disable trust/ident but leaves them on in the standard
> configuration. I do not want to disable "trust" by default for everyone,
> but it would be great to have the option to do this without having to
> patch (and thus test and verify) the PostgreSQL sources for each new
> release.
Any new compile-time option creates a nonlinear maintenance burden.
We're going to need to test whether each option builds cleanly and
works, also in combination with other options, and on several platforms.The authentication code is already littered
withbuild-time
dependencies and platform-specific code. So the "it doesn't bother
anyone" argument doesn't quite work.
Actually, in this particular case, you wouldn't even need a compile-time
option. You could just make it a restart-only option.
> I think this is a sufficiently general requirement to warrant including
> an option to disable this, as most hardening guides I have seen for
> PostgreSQL unconditionally require to disable trust authentication and
> disabling it in the code removes the need to check this in the runtime
> configuration.
I think people would be interested in well-thought out, generalized
hardening facilities. But that would likely include other things than
just disabling an authentication method or two. And we can't be adding
a new compile-time option as we add each one. We need a more general
approach.
> Single user sessions would work, but the "peer" authentication is also
> still available and should be the preferred method to reset passwords
> when trust is disabled, so this should not be an issue.
"peer" authentication is unfortunately not quite portable.