Re: Credcheck- credcheck.max_auth_failure

On 2024-12-16 10:37:59 -0500, Ron Johnson wrote:
> 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

No, it doesn't. PAM is used to authenticate a user to the OS (plus to do
a bit of setup and teardown at the beginning and end of each session).
But here the user is already authenticated to the OS and postgresql is
using that information to authenticate the user to itself. This will use
the nsswitch mechanism on Linux (and probably something similar on the
other OSs) to do the uid->username lookup, but it will not use PAM,
since that simply isn't what PAM is for (or capable of to my knowledge).

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!"