Re: Logging of PAM Authentication Failure - Mailing list pgsql-hackers

>>> I created a patch which enables it to use the existing connection in
>>> such a case (unlike what we currently do). It modifies
>>> connectDBComplete() and PQconnectPoll() to also include states
>>> pertaining to password being accepted from the user. That is, the
>>> state machine in PQconnectPoll() is further extended to include a
>>> connection state called CONNECTION_ASKING_PASSWORD which is entered
>>> when server sends AUTH_REQ_MD5 or AUTH_REQ_PASSWORD auth requests.
>>
>> Great! The new client state seems to be effective also for MD5.  But
>> it seems to break existing libpq client doing the same authentication
>> sequence as current psql. Some means would be necessary to switch the
>> behavior when password is not previously provided but needed by the
>> server, or make the first half of the connection sequence to be
>> compatible to the current sequence - in other words - It should be
>> that when the user finds stauts is CONNECTION_BAD and
>> PQconnectionNeedsPassword() == true, the user can throw away the
>> connection and make new connection providing password, and also can
>> send password on existing connection.
>
> The first half of connection sequence remains same except for one
> change: in PQconnectPoll(), when in case CONNECTION_AWAITING_RESPONSE,
> if server sends md5/password authentication request, it returns
> PGRES_POLLING_WAITING_PASSWORD, which, back in connectDBComplete()
> sets conn->password = true and conn->status =
> CONNECTION_ASKING_PASSWORD. Back in main(), this causes a password
> prompt and then the second half of the connection sequence. Hence
> pg_fe_sendauth() is not called in this first half unless it's a
> different authentication method than md5 and password.

One more thing that I forgot to mention is that connection sequence
would enter CONNECTION_ASKING_PASSWORD in the first half, only if
password is currently not set to a non-empty value that is (
conn->pgpass ==NULL || conn->pgpass[0] = '\0' ) is true. I was
wondering what would be the case for other applications using libpq
when they return from connectionDBComplete() with conn->status set to
CONNECTION_ASKING_PASSWORD, provided they have not set conn->pgpass to
a non-empty value.If they are currently handling this based on
CONNECTION_BAD, then this change does no good to them. In fact there
needs to be a way for them to get CONNECTION_BAD.
Since, this whole patch is about not having to drop-and-reconnect *in
case of password prompt*, how it changes libpq for other applications
also needs to be addressed here. especially for md5/password
authentication cases. Currently, any attempt to connect using empty or
NULL password results in CONNECTION_BAD for all libpq based clients.
Thoughts?