From: | Amit Langote <amitlangote09(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Logging of PAM Authentication Failure |
Date: | 2013-05-12 13:38:00 |
Message-ID: | CA+HiwqGU6Vevw4aWkaUZJUgxb_9SjRYwypJpi5U+V7dD2gTmyQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> 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?
--
Amit Langote
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Nasby | 2013-05-12 20:18:35 | Re: Proposal to add --single-row to psql |
Previous Message | Fabien COELHO | 2013-05-12 06:59:37 | Re: [PATCH] add long options to pgbench (submission 1) |