Horton

Thread

Commits

  1. Tweak some authentication debug messages to follow project style.

  2. Avoid logging complaints about abandoned connections when using PAM.

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

    La Cancellera Yoann <lacancellera.yoann@gmail.com> — 2019-10-11T08:38:58Z

    Hi,



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:

2019-10-10 15:00:46.481 CEST [6109] LOG: pam_authenticate failed:
Authentication failure
2019-10-10 15:00:46.481 CEST [6109] FATAL: PAM authentication failed for
user "ylacancellera"
2019-10-10 15:00:46.481 CEST [6109] DETAIL: Connection matched pg_hba.conf
line 5: "local all all pam"
2019-10-10 15:00:46.481 CEST [6109] LOG: could not send data to client:
Broken pipe


And if auth is unsuccessful, it will log that very same message twice


My pg_hba is basically :

local           all        postgres                   peer

local           all        all                               pam


Any idea about this ? I suspect something is wrong

Thank you,

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

    Tom Lane <tgl@sss.pgh.pa.us> — 2019-10-11T14:08:37Z

    La Cancellera Yoann <lacancellera.yoann@gmail.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

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

    Tom Lane <tgl@sss.pgh.pa.us> — 2019-11-04T17:01:46Z

    [ redirecting to pgsql-hackers ]

I wrote:
> La Cancellera Yoann <lacancellera.yoann@gmail.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.

I took a closer look at this and realized that the problem is that
the PAM code doesn't support our existing convention of not logging
anything about connections wherein the client side disconnects when
challenged for a password.  0001 attached fixes that, not in a
terribly nice way perhaps, but the PAM code is already relying on
static variables for communication :-(.

Also, 0002 adjusts some messages in the same file to match project
capitalization conventions.

Barring objections, I propose to back-patch 0001 but apply 0002
to HEAD only.

			regards, tom lane