| From: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> | 
|---|---|
| To: | amitlangote09(at)gmail(dot)com | 
| Cc: | tgl(at)sss(dot)pgh(dot)pa(dot)us, robertmhaas(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org | 
| Subject: | Re: Logging of PAM Authentication Failure | 
| Date: | 2013-05-14 01:38:26 | 
| Message-ID: | 20130514.103826.188326109.horiguchi.kyotaro@lab.ntt.co.jp | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
> 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.
Well, if we are allowed to use a bit ugry way, the attached patch
seems to cope with this issue. As far as I can see there's no
problem since pg_fe_sendauth() refueses to send empty password.
Any suggestions?
> 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?
Sorry, I've read there incorrectly. I had understood the code
after sendAuthRequest in pam_passwd_conv_proc but it is used
indeed.
regards,
-- 
Kyotaro Horiguchi
NTT Open Source Software Center
| Attachment | Content-Type | Size | 
|---|---|---|
| unknown_filename | text/plain | 1.3 KB | 
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jon Nelson | 2013-05-14 01:54:39 | fallocate / posix_fallocate for new WAL file creation (etc...) | 
| Previous Message | Marti Raudsepp | 2013-05-14 01:12:41 | PostgreSQL 9.3 beta breaks some extensions "make install" |