On Mon, Dec 16, 2024 at 10:19 AM Peter J. Holzer <hjp-pgsql@hjp.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.
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@hjp.at | -- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!"
