BUG #15520: PAM authentication + domain socket -> DNS query for symbolic hostname [local]
The Post Office <noreply@postgresql.org>
From: PG Bug reporting form <noreply@postgresql.org>
To: pgsql-bugs@lists.postgresql.org
Cc: albert_schabhuetl@yahoo.de
Date: 2018-11-24T10:45:54Z
Lists: pgsql-bugs
The following bug has been logged on the website: Bug reference: 15520 Logged by: Albert Schabhuetl Email address: albert_schabhuetl@yahoo.de PostgreSQL version: 10.4 Operating system: RHEL 7.4 Description: When PAM authentication is configured for local connections via domain socket, during authentication the backend process sends out a DNS query for the following symbolic hostname: [local] This is unnecessary as it is not intended that this hostname will ever resolve to a valid IP address, and depending on how DNS queries are answered in the actual system it can cause authentication delays. Theory why this happens: Since this commit https://github.com/postgres/postgres/commit/2f1d2b7a75fecad25295cb3f453503eb6a176d4f#diff-f5a9c53142c3595fe47ebf5146457c6b during PAM authenticaion the functions pg_getnameinfo_all pam_set_item are called, in order to support the PAM configuration option "pam_use_hostname". In the case of a TCP connection and pam_use_hostname = 0, pg_getnameinfo_all still calls the library function getnameinfo but with flags = 0 to achieve "do nothing" behaviour. In the case of a domain socket connection, regardless of pam_use_hostname, pg_getnameinfo_all calls getnameinfo_unix, which ignores the flags parameter and invariably sets the hostname to a symbolic text - [local] in our case. When subsequently the PAM library function pam_set_item is called, it gets the symbolic hostname [local] and probably it is this function which sends the DNS request for this hostname.
Commits
-
Don't set PAM_RHOST for Unix sockets.
- 63d8350665c8 9.6.12 landed
- 96ed0b870454 10.7 landed
- 0640d9517e7e 11.2 landed
- 0f9cdd7dca69 12.0 landed
-
Set PAM_RHOST item for PAM authentication
- 2f1d2b7a75fe 9.6.0 cited