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

From Kyotaro HORIGUCHI
Subject Re: Logging of PAM Authentication Failure
Date
Msg-id 20130513.162545.168015968.horiguchi.kyotaro@lab.ntt.co.jp
Whole thread Raw
In response to Re: Logging of PAM Authentication Failure  (Amit Langote <amitlangote09@gmail.com>)
Responses Re: Logging of PAM Authentication Failure  (Amit Langote <amitlangote09@gmail.com>)
List pgsql-hackers
Hello,

> > auth_failed() in src/backend/libpq/auth.c intentionally logs nothing for
> > STATUS_EOF status (ie, client closed the connection without responding).
> > But it looks like the PAM code path doesn't have a way to return that
> > status code, even when pam_passwd_conv_proc() knows that that's what
> > happened, and intentionally printed no log message itself (around line
> > 1870 in HEAD).  If there's another response code we could return through
> > the PAM layer, this could be fixed, and I think it should be.
> 
> So if I get this correctly, does this mean the only thing that needs
> to be fixed is unnecessary logging or is there a problem with
> authentication exchange itself in case of PAM? Also, when you say PAM
> layer, is that pam_passwd_conv_proc() that needs to be able to return
> an alternative status code?

Following is the point server requests psql to send password when
PAM is enabled.

backend/libpq/auth.c:1861
>   if (strlen(passwd) == 0)
>   {
>     /*
>      * Password wasn't passed to PAM the first time around -
>      * let's go ask the client to send a password, which we
>      * then stuff into PAM.
>      */
>     sendAuthRequest(pam_port_cludge, AUTH_REQ_PASSWORD);
>     passwd = recv_password_packet(pam_port_cludge);
>     if (passwd == NULL)
>     {
>       /*
>        * Client didn't want to send password.  We
>        * intentionally do not log anything about this.
>        */
>       goto fail;
...
>    return PAM_CONV_ERR;


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?

regards,

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Proposal to add --single-row to psql
Next
From: Heikki Linnakangas
Date:
Subject: Re: Fast promotion failure