Re: Issues with PAM : log that it failed, whether it actually failed or not

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: La Cancellera Yoann <lacancellera(dot)yoann(at)gmail(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Issues with PAM : log that it failed, whether it actually failed or not
Date: 2019-10-11 14:08:37
Message-ID: 15705.1570802917@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

La Cancellera Yoann <lacancellera(dot)yoann(at)gmail(dot)com> writes:
> I am having issues with PAM auth :
> it works, password are correctly checked, unknown users cannot access,
> known user can, everything looks good
> But, it always log an error by default even if auth is succesful:
> And if auth is unsuccessful, it will log that very same message twice

Those aren't errors, they're just log events.

If you're using psql to connect, the extra messages aren't surprising,
because psql will first try to connect without a password, and only
if it gets a failure that indicates that a password is needed will
it prompt the user for a password (so two connection attempts occur,
even if the second one is successful). You can override that default
behavior with the -W switch, and I bet that will make the extra
log messages go away.

Having said that, using LOG level for unsurprising auth failures
seems excessively chatty. More-commonly-used auth methods aren't
that noisy.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Dmitry Dolgov 2019-10-11 14:16:24 Re: JSON vs. JSONB storage size
Previous Message Matthias Apitz 2019-10-11 14:08:08 Re: Perl DBI converts UTF-8 again to UTF-8 before sending it to the server

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeremy Finzel 2019-10-11 14:19:33 Re: BRIN index which is much faster never chosen by planner
Previous Message Jeremy Finzel 2019-10-11 14:08:05 Re: BRIN index which is much faster never chosen by planner