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 with build-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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
