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

From Amit Langote
Subject Re: Logging of PAM Authentication Failure
Date
Msg-id CA+HiwqG5QQgJ8WtV78FjuiGog8DjKd=dhFVT92d=-+54PTReKw@mail.gmail.com
Whole thread Raw
In response to Re: Logging of PAM Authentication Failure  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Responses Re: Logging of PAM Authentication Failure  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
List pgsql-hackers
> This code seems to me expecting for psql to send password without
> closing current connnection.On the other hand psql does as
> follows.
>
> bin/psql/startup.c: 227
>>    pset.db = PQconnectdbParams(keywords, values, true);
>>    free(keywords);
>>    free(values);
>>
>>    if (PQstatus(pset.db) == CONNECTION_BAD &&
>>      PQconnectionNeedsPassword(pset.db) &&
>>      password == NULL &&
>>      pset.getPassword != TRI_NO)
>>    {
>>      PQfinish(pset.db);
>>      password = simple_prompt(password_prompt, 100, false);
>>      new_pass = true;
>>    }
>
> psql at once disconnects the current connection and reconnects
> with this new password, so pam_conv_err is observed in server.
>
> It seems to be a kind of protocol-mimatching. Client should'nt
> disconnect for password request or server should fit to what psql
> does. Is this wrong?

In fact, this is the behavior with all the authentication methods that
require a password. But, it is only in the case of PAM authentication
that auth_failed() logs error when first connection attempt is made
(without password), since the STATUS_EOF is not passed to it in that
case.
If we did not drop the connection (unlike what we do now) and
re-attempted connection with the password added to conn, would the
backend's authentication state still be waiting for the password? Can
we do away without having to create a second connection?
--
Amit Langote



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Fast promotion failure
Next
From: Mark Salter
Date:
Subject: lock support for aarch64