On Wed, May 6, 2015 at 4:47 PM, Alvaro Herrera <alvhe...@2ndquadrant.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 >
