Re: Disabling trust/ident authentication configure option

On Wed, May 6, 2015 at 4:47 PM, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
wrote:

> Robert Haas wrote:
>
> > I frankly find that a bit difficult to swallow. You think that
> > everyone knows that bad passwords are a problem, but some people might
> > not realize that an authentication method called "trust" might not be
> > secure?
>
> Ultimately, what we offer to users is choice of a few options. Should
> we only offer options that we consider to be completely secure, and no
> others? If we were to follow that principle, we would completely
> disable non-SSL builds, and all auth methods other than, I dunno, GSSAPI
> and such. But we don't do that, because we trust that users will use
> whatever is most appropriate for them. I see this patch is, in a way, a
> mechanism to let system administrators choose at compile time what
> options are available to DBAs at setup time. This seems a reasonable
> thing to me.
>
>
Yes in fact, it would be a way for organizations distributing their own
PostgreSQL packages to enforce authentication restrictions within the
package instead of having to educate all users about the options.

> I don't necessarily agree with the patch as proposed. I would rather
> have a comma-separated list of methods, as in:
>
> --disable-auth=ident,peer
>

Something more general like that would be even better, and when reading the
comments below perhaps also the option to differentiate between local and
remote authentication. I will look into this and see if we could update the
patch to a more generic option in case people here agree that it is
worthwhile.

I would be adding additional options:

--disable-remote-auth=ident,trust
--disable-local-auth=trust

And would check that there is a warning about the password reset
restrictions in case both peer and trust (and on Windows?) are disabled.

>
> which lets you choose what to disable without hardcoded choices. Due to
> the nature of autoconf, this might be too fiddly to implement, though,
> and if so I think the method proposed by this patch seems a reasonable
> compromise. I've seen configure in other programs offer options such as
> --disable-foo=list that lists acceptable values (or --disable-foo=help)
>
> --
> Álvaro Herrera http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>