Re: Credcheck- credcheck.max_auth_failure

On Mon, Dec 16, 2024 at 10:19 AM Peter J. Holzer <hjp-pgsql(at)hjp(dot)at> wrote:

> On 2024-12-16 09:17:25 -0500, Ron Johnson wrote:
> > Local (socket-based) connections are typically peer-authenticated
> > (meaning that authentication is handled by Linux pam).
> ^^^
> Is it? I haven't checked the source code, but this doesn't seem
> plausible. You can get the uid of a socket peer directly from the
> kernel, which can be converted to a user name via getpwuid, and the
> mapping to postgresql roles is done via pg_ident.conf. I see no role for
> PAM in that path.
>

https://www.postgresql.org/docs/16/auth-peer.html

"
The peer authentication method works by obtaining the client's operating
system user name from the kernel and using it as the allowed database user
name (with optional user name mapping). This method is only supported on
local connections.
[snip]
Peer authentication is only available on operating systems providing the
getpeereid() function, the SO_PEERCRED socket parameter, or similar
mechanisms. Currently that includes Linux, most flavors of BSD including
macOS, and Solaris.
"

That means pam (and presumably also ldap and sssd), since there must be an
OS user with the same name, and OS authentication is handled by pam, ldap
and sssd.

$ grep peer '$PGDATA'/pg_hba.conf
local all all peer

>
> > Thus, if someone enters too many wrong passwords for a superuser
> > account, you should still be able to locally connect to PG.
>
> True. But the client may not be on the same machine.
>
> hp
>
> --
> _ | Peter J. Holzer | Story must make more sense than reality.
> |_|_) | |
> | | | hjp(at)hjp(dot)at | -- Charles Stross, "Creative writing
> __/ | http://www.hjp.at/ | challenge!"
>

--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!