From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Volker Aßmann <volker(dot)assmann(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Disabling trust/ident authentication configure option |
Date: | 2015-05-06 14:47:24 |
Message-ID: | 20150506144724.GU2523@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
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
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
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2015-05-06 14:53:31 | Re: INSERT ... ON CONFLICT syntax issues |
Previous Message | Pavel Stehule | 2015-05-06 14:35:32 | Re: Manipulating complex types as non-contiguous structures in-memory |