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: | Raw Message | Whole Thread | 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" |