Re: Logging of PAM Authentication Failure

From: Craig Ringer <craig(at)2ndquadrant(dot)com>
To: Amit Langote <amitlangote09(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Logging of PAM Authentication Failure
Date: 2013-05-29 00:12:23
Message-ID: 51A547E7.8010708@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 05/28/2013 04:04 PM, Amit Langote wrote:
> On Tue, May 28, 2013 at 2:32 PM, Craig Ringer <craig(at)2ndquadrant(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Craig Ringer 2013-05-29 00:32:27 Re: Planning incompatibilities for Postgres 10.0
Previous Message Andres Freund 2013-05-29 00:00:42 Re: preserving forensic information when we freeze