Re: Logging of PAM Authentication Failure
| От | Craig Ringer |
|---|---|
| Тема | Re: Logging of PAM Authentication Failure |
| Дата | |
| Msg-id | 51A547E7.8010708@2ndquadrant.com обсуждение исходный текст |
| Ответ на | Re: Logging of PAM Authentication Failure (Amit Langote <amitlangote09@gmail.com>) |
| Список | pgsql-hackers |
On 05/28/2013 04:04 PM, Amit Langote wrote: > On Tue, May 28, 2013 at 2:32 PM, Craig Ringer <craig@2ndquadrant.com> wrote: >> On 05/11/2013 03:25 AM, Robert Haas wrote: >>> Not really. We could potentially fix it by extending the wire >>> protocol to allow the server to respond to the client's startup packet >>> with a further challenge, and extend libpq to report that challenge >>> back to the user and allow sending a response. But that would break >>> on-the-wire compatibility, which we haven't done in a good 10 years, >>> and certainly wouldn't be worthwhile just for this. >> We were just talking about "things we'd like to do in wire protocol 4". >> >> Allowing multi-stage authentication has come up repeatedly and should >> perhaps go on that list. The most obvious case being "ident auth failed, >> demand md5". >> > I wonder what you think about continuing to use the already > established connection to the server while you move onto perform > authentication using next method in the list. That's precisely what I'm talking about. It'd be nice to avoid the ugly two-connection approach for SSL too, by allowing STARTTLS or similar within the protocol. Being able to negotiate connections - client says "peer?", server says "failed, peer id doesn't match postgresql username", client says "md5 <password>?" server says "yup, that's ok" - would be nice. For example, use Kerberos or SSPI where clients are suitably enabled, then fall back to MD5 where Kerberos or SSPI single-sign-on isn't available. -- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: